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
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
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 :
* 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
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
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
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
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
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
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
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,
11 matches
Mail list logo