Re: [elm-discuss] Re: [Suggestion] Type values and simplifying the language still

I made a TL;DR : https://gist.github.com/Warry/ca83e06f92bfc9bd866a33ed97bbc6f8 On Monday, January 16, 2017 at 1:51:40 PM UTC+1, Maxime Dantec wrote: > > Actually, we could get rid of the keyword entierly : > > Faz = (Int, Int) > Faz : ø > > Fiz = { name : String, age : Int } > Fiz : ø > > Fuz a

Re: [elm-discuss] Re: [Suggestion] Type values and simplifying the language still

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

Re: [elm-discuss] Re: [Suggestion] Type values and simplifying the language still

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 :

Re: [elm-discuss] Re: [Suggestion] Type values and simplifying the language still

* 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

Re: [elm-discuss] Re: [Suggestion] Type values and simplifying the language still

Max, apparently you didn’t understand what Maxime’s proposal is *at all*. For example, he didn’t propose anything that would change the existence of this type: type Direction = Up | Down | Left | Right ​ 2017-01-15 23:47 GMT+01:00 Max Goldstein : > First, I appreciate

[elm-discuss] Re: [Suggestion] Type values and simplifying the language still

First, I appreciate that this proposal is being made in the spirit of Elm: seeking to simplify the language, with reference to existing usage (red sentence in the first post), and trying to solve an existing problem (serialization of union types). It's clear that Maxime wants to learn and

Re: [elm-discuss] Re: [Suggestion] Type values and simplifying the language still

I don't think this would actually make the language simpler, for the following reason: *Flat is Better than Nested* When you only allow one value per tag, you end up having records/tuples nested inside of tagged-union types. Your nesting gets deeper and more complex. So while it clearly makes

[elm-discuss] Re: [Suggestion] Type values and simplifying the language still

There must be a way where we have functions for constructor AND labels for serialization. I'm pretty sure I'm not going to find a solution, and it will not be on my laptop tomorrow anyway ;-) Just glad some people share my concerns. -- You received this message because you are subscribed to

[elm-discuss] Re: [Suggestion] Type values and simplifying the language still

Just to chime in about automatic serialization/deserialization, reading other threads, it seems the big question is what the JSON would look like. I propose this: {"tag": "Maybe.Just", "$0": 5} The tag field contains the constructor name, fully-qualified to prevent ambiguities between

[elm-discuss] Re: [Suggestion] Type values and simplifying the language still

I agree that automatic serialization/deserialization of union types is orthogonal to this idea, but I am default interested in any language simplification! Ignoring ctor implications, here are my initial thoughts on that idea on its own merits: - These union type constructors are functions

[elm-discuss] Re: [Suggestion] Type values and simplifying the language still

Sorry! Forgot to mention... The automatic serializer/deserializers in the ports is assuming that the main reason behind not serializing ADTs in the first place was this { _0, _1... _n } shape. The "native" object could also swap ctor to type: {type:"TypeValue", value: xx} it's a type value,