On Tuesday, February 21, 2017 at 2:16:55 AM UTC, Max Goldstein wrote:
>
> Records can still be useful in union types if you have more than a few
> fields, or multiple fields of the same type. Often you write a function
> that updates a record by looking at a select few fields and it never needs
Records can still be useful in union types if you have more than a few
fields, or multiple fields of the same type. Often you write a function
that updates a record by looking at a select few fields and it never needs
to know about others. Occasionally you will have multiple records of this
sor
On Wednesday, February 15, 2017 at 8:49:13 PM UTC, Rupert Smith wrote:
>
> I am trying to build a model with states, such that fields are only
> available that are actually needed in the relevant state. The model is like
> this:
>
> type alias WithPosition a =
> { a | rect : Rectangle }
>
>
On Wednesday, February 15, 2017 at 8:49:13 PM UTC, Rupert Smith wrote:
>
> What I don't understand is why this fails to type check:
>
> mapWhenWithPosition : (WithPosition b -> a) -> State -> Maybe a
> mapWhenWithPosition func state =
> case state of
> Aware rect ->
> Just <
On Wednesday, February 15, 2017 at 10:19:34 PM UTC, Max Goldstein wrote:
>
> I think this code would be simpler, and no less expressive, if the
> function argument was Rectangle -> a. The fact that it's wrapped with some
> arbitrary fields is mixing concerns.
>
Yes, I did in fact start out with
On Wednesday, February 15, 2017 at 8:49:13 PM UTC, Rupert Smith wrote:
>
> What I don't understand is why this fails to type check:
>
> mapWhenWithPosition : (WithPosition b -> a) -> State -> Maybe a
> mapWhenWithPosition func state =
> case state of
> Aware rect ->
> 105:Ju
I honestly don't know if your code "should" typecheck or not, but if it
did, it wouldn't do anything more than what you already have. The function
you pass would only have access to the rect field. I think this code would
be simpler, and no less expressive, if the function argument was Rectangle
On Wednesday, February 15, 2017 at 8:49:13 PM UTC, Rupert Smith wrote:
>
> This would seem to make extensible records a lot less useful than they
> could be. Is this one of those cases where an existential qualifier would
> be needed to specify the type of the function? Or is this in fact a case
On Friday, February 10, 2017 at 3:26:38 PM UTC, Joey Eremondi wrote:
>
> So, Elm lets you do a forall over the rest of a record.
>
> {a | x : Int} -> Int says this function accepts any record that has an x
> Int field.
>
I am trying to build a model with states, such that fields are only
availab
So, Elm lets you do a forall over the rest of a record.
{a | x : Int} -> Int says this function accepts any record that has an x
Int field.
The problem is when you want a list of them. List {a | x : Int} only lets
you make a list of records with the same type filling in for a.
With existential t
On Friday, February 10, 2017 at 3:10:57 PM UTC, Joey Eremondi wrote:
>
> It's usually called row polymorphism, and isn't really subtyping, although
> you get something like subtyping if you combine it with existential types,
> which would lose decidability.
>
Yes, Ob<: had existential types. It
Here's the paper you're looking for:
https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/scopedlabels.pdf
I believe it's fully decidable. Elm is basically Damas Milner plus these
records, so it stays decidable.
It's usually called row polymorphism, and isn't really subtyping, alth
For my undergraduate project (20+ years ago), I implemented a language
called Ob<: (or ObSub) from "A Theory of Objects" by Abadi and Cardelli.
This language is related to the functional language F<: (functional
calculus with sub-typing), which is somewhat related to F#. My project
supervisor w
13 matches
Mail list logo
