I made a TL;DR :
https://gist.github.com/Warry/ca83e06f92bfc9bd866a33ed97bbc6f8
On Monday, January 16, 2017 at 1:51:40 PM UTC+1, Maxime Dantec wrote:
>
> Actually, we could get rid of the keyword entierly :
>
> Faz = (Int, Int)
> Faz : ø
>
> Fiz = { name : String, age : Int }
> Fiz : ø
>
> Fuz a = { a | age : Int }
> Fuz : ø
>
> Foo
> = Foo
> | Bar Int
> | Baz (String, String)
> * | Biz { name : String, age : Int }*
> * | Buz Fiz*
>
>
> * | Boz (Fuz { name : String })*Foo : Foo
> Bar : Int -> Foo
> Baz : String -> String -> Foo
>
> *Biz : String -> Int -> Foo**Buz : String -> Int -> Foo*
>
>
>
>
> *Boz : String -> Int -> FooDoo a =... *
> On Monday, January 16, 2017 at 1:43:02 PM UTC+1, Maxime Dantec wrote:
>>
>> Thanks for the answers, I had indeed made some poor choices of word in my
>> first email :(
>>
>> Just before this thread dies, and out of the blue : What if...
>>
>> - type alias never generates a constructor (change: records do not have
>> ctors)
>> - type always generate an "expanded" ctor
>>
>> expanded as in :
>>
>> type alias Faz = (Int, Int)
>> Faz : ø
>>
>> type alias Fiz = { name : String, age : Int }
>> Fiz : ø
>>
>> type alias Fuz a = { a | name : String }
>> Fuz : ø
>>
>> type Foo
>> = Foo
>> | Bar Int
>> | Baz (String, String)
>> * | Biz { name : String, age : Int }*
>>
>> * | Buz Fiz*
>> Foo : Foo
>> Bar : Int -> Foo
>> Baz : String -> String -> Foo
>>
>>
>> *Biz : String -> Int -> FooBuz : String -> Int -> Foo*
>> On Monday, January 16, 2017 at 6:56:52 AM UTC+1, Max Goldstein wrote:
>>>
>>> * rereads * Janis, you are incredibly good at telling people that
>>> they're wrong.
>>>
>>> Ah, I got caught up in the third paragraph about the native
>>> representation, and thought that those were Elm records, not JavaScript
>>> objects.
>>>
>>> Also, the phrase "No type value has more than one value", for all of its
>>> bold redness, reads perilously close to "no type has more than one tag".
>>>
>>> However, I think there's some value in pointing out the legitimacy of
>>> tags that have no arguments: under the proposal, union tags would still
>>> have either one argument or none, just not more than one. One of the more
>>> confusing parts of union types is that different tags can be functions of
>>> different arities or non-function values, depending on how they are
>>> defined. If we wanted to eliminate this confusion, we could require an
>>> arity of exactly one, and tags like Up and Down would need to be Up () and
>>> Down ().
>>>
>>> But that's needlessly confusing, so limiting the number of tags to one
>>> seems more like a restriction than a simplification. Yes, you've found a
>>> way to make a strictly smaller language without diminishing expressive
>>> power. The same is true for requiring f x y = ... to be written as f = \ x
>>> y -> ... but no one is advocating for that.
>>>
>>> So, I'm sorry I misunderstood your proposal and lectured on things you
>>> may well have known about. And for what it's worth, I've used two-argument
>>> constructors before, and I've advocated for records instead of positional
>>> arguments before. I think this is a place where we can allow some freedom
>>> to the programmer.
>>>
>>>
--
You received this message because you are subscribed to the Google Groups "Elm
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
