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.
