Your example is not even type correct. And even if it were, I don't see how it
would contradict my point. The constructor wouldn't be partially applicable.
You would have to define a separate function for that. Bad for reuse and
refactorability.
> Am 15.01.2017 um 17:15 schrieb Maxime Dantec <he...@warry.fr>:
>
> Not really, take this example :
>
> type Foo = Bar ( Int, Bool, (String, Foo) )
>
> foo : Int -> Bool -> (String, Foo) -> Foo
> foo = Foo << (,,)
>
> And again, it seems to be the exception to have multiple values.
>
>> 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>:
>>>
>>> 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.
>>> 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.
--
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.
