I had to explain two concepts lately: ADTs and ports. It's not that it's
_that_ complicated, but it's not self explanatory neither.
The key point of ADTs is polymorphism, holding a finite number of
heterogeneous values seems to be tuples' or records' job.
It's also weird that port values and elm values are not the same (tuples
are transformed to native arrays, and maybes to nullable).
On Sunday, January 15, 2017 at 5:09:46 PM UTC+1, Janis Voigtländer wrote:
>
> This would take away the possibility of partially applying the
> constructors like Bar. Not a good idea. There's a reason these have curried
> types.
>
>
> Am 15.01.2017 um 17:03 schrieb Maxime Dantec <he...@warry.fr <javascript:>
> >:
>
> Not really, sorry I assumed that everybody knew how elm compile values but
> it was very presumptuous. Currently, all type values in Elm are converted
> in Javascript values in the { ctor, _0, _1... _n } shape. For example,
> Nothing becomes { ctor: "Nothing" } and (Just 10) becomes { ctor :
> "Just", _0: 10 }. The {type, value} part, would change that to : Nothing
> becomes { type: "Nothing" } and (Just 10) becomes { type : "Just", value:
> 10 }.
>
> The { ctor, _0, _1... _n } shape is, *I assume*, why we can't
> automatically send type values though ports. The rationale is: if it's
> really the reason, since we barely use more than one value in type values,
> why not facilitate port usage instead of larger type values. Does it makes
> sense at all?
>
> In other words, currently you can do that:
>
> type Foo = Foo | Bar Int Bool (String, Foo)
> where: Bar : Int -> Bool -> (String, Foo) -> Foo
> that you use like this in elm: Bar 1 False ("fooBar", Foo)
> which compiles down to in js: { ctor: "Bar", _0: 10, _1: false, _2: {
> ctor: "Tuple2", _0: "fooBar", _1: { ctor: "Foo"} } }
>
> It would become impossible, because the type value Bar has 3 values.
> Instead, you would have to give only one value to the Bar constructor :
>
> type Foo = Bar { id: Int, isSomething: Bool, foo: (String, Foo) }
> where: Bar : { id: Int, isSomething: Bool, foo: (String, Foo) } -> Foo
> that you would use like this: Bar { id = 0, isSomething = False, foo = ("
> fooBar", Foo) }
> would compiles down to: { type: "Bar", value: { id: 0, isSomething:
> false, foo: ["fooBar", { type: "Foo" }] } }
>
> The record could be as well replaced by a Tuple ( Int, Bool, (String,
> Foo) )
>
> I hope it's clearer enough?
>
> On Sunday, January 15, 2017 at 4:33:50 PM UTC+1, Duane Johnson wrote:
>>
>> I'm trying to see if I understand your suggestion correctly.
>>
>> So would an enumeration like this:
>>
>> type Msg
>> = ClickedButton
>> | EnteredAge value
>> | EnteredHeight value
>>
>> become...
>>
>> type Msg = { action : String, value : String }
>>
>> ?
>>
>> I'm trying to figure out how you'd "authorize up to one value" in a
>> situation like this, since the whole point of an enumeration is to allow
>> multiple possibilities.
>>
>> Duane
>>
>> On Sun, Jan 15, 2017 at 6:59 AM, Maxime Dantec <he...@warry.fr> wrote:
>>
>>> Hi folks,
>>>
>>> The last 3 versions of elm were somewhat unusual for a young programing
>>> language: features were removed and it has been simplified, to the point
>>> that you can't remove anything else. Well, about that.
>>>
>>> I believe that the last thing that could be simplified still are ADT. *No
>>> type value has more than one value in the core repository*, with the
>>> exception of Dict and Color. I have used a few types with more than one
>>> value myself, but I hardly see the difference with a type value that has 3
>>> values and a type value that has a tuple3 as unique value, if you except
>>> the constructor signature. Does yourself make an intensive usage of this
>>> feature?
>>>
>>> So here is my suggestion: Why not authorize up to one value to type
>>> values? If you need to bundle values, you can still use a tuple or a
>>> record. The reasoning behind this, is to get rid of the _0, _1, _2 in the
>>> "native" part of the type values. we could have {ctor:"Enum"} or
>>> {ctor:"TypeValue",
>>> value: {...}}, and why not automatic serializer/deserializers in the
>>> ports thanks to this too?
>>>
>>> Everyone has an opinion, and it's very easy to make a suggestion while
>>> not implementing it. I'm not pretending that this is a good idea, I humbly
>>> think that it's worth mentioning given that it's in the scope of
>>> simplifying the language. Please share you opinion :)
>>>
>>> Cheers!
>>>
>>> --
>>> 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 elm-discuss...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> 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 elm-discuss...@googlegroups.com <javascript:>.
> For more options, visit https://groups.google.com/d/optout.
>
>
--
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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
