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 <[email protected]>: > > 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 <[email protected]> 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 [email protected]. >>> 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 [email protected]. > 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
