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 serialization and deserialization. The compiler could
generate a lookup table to determine not only how many arguments should be
passed to the constructor (solving the problem mentioned in OP) but also
their types.
Everything else is similar to the field schema used by Native modules,
except with $ instead of _. I understand that browsers do undesirable
things to object keys that can be parsed as integers, so it's important
that the indices be prefixed with some non-numeric character like _ or $.
I think $ is a more human-friendly prefix than _, because it appears in the
wild: $ followed by an index refers to regular expression capture groups in
languages including JS, Perl, and Ruby, e.g.
"Sam Sample".replace(/(\w+)\s(\w+)/, "$2, $1" === "Sample, Sam"`
An alternative (which I like less) was proposed elsewhere
<https://github.com/elm-lang/elm-compiler/issues/490#issuecomment-34403615> and
looks like this:
{"tag": "Maybe.Just", "contents": [5]}
The idea being that if the union type holds multiple values, we just stick
them in the heterogeneous contents array. This might look less weird to
someone comfortable with JS, but using it would be worse. It would
encourage iteration when iteration makes no sense, and it would have worse
lookup performance than object fields would.
--
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.
