yeah, it should be Bar << (,,) (there are no compile errors in the mail client).
I'm sorry to insist, but I am well aware of what it means to limit type values' size, that's the reason of this thread. - 95% of my types have 0 or 1 value - the 5% seems to be why we can't serialize values automatically - composition is made harder, but still possible for those 5% To me, the real question is : Do we prefer to compose ctors or simplify the syntax and serialization ? On Sunday, January 15, 2017 at 5:49:17 PM UTC+1, Janis Voigtländer wrote: > > 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 <[email protected] <javascript:> > >: > > 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 <[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] <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 [email protected]. For more options, visit https://groups.google.com/d/optout.
