Yeah just to be clear to Ian, I absolutely agree that a general macro system would be more trouble than it would be worth. It has a place in some languages but would take away from the simplicity that Elm promises - and increasingly delivers on. 0.17 was a big increment in that sense by making interfacing with JS and the external world in general more approachable.
I really was just hopping on the observation about JSON serialization and pointing out it has been talked about. If a future release could alleviate the currently somewhat cumbersome way of marshalling between JSON and Elm, that would be another great increment. Something along the lines that Max and Peter suggest would be awesome. I am impressed by Elm's conservative approach in not granting developers (or DSL authors who might want macros) everything they might want, whilst still giving them what they need. In this case, not getting macros but getting compiler generated serialization would be a great outcome. On Friday, June 17, 2016 at 4:48:42 PM UTC+10, Peter Damoc wrote: > > It's not a horrible idea to have encodeUser/decodeUser but why not go one > step further and have an internal typeclass like serializable that would > only be used in the Json libraries. Also, pick a standard encoding for the > UnionTypes so they can become serializable as well. This will allow for > compiler time errors if you try to serialize something that is not > serializable and would simplify the handling of Json tremendously and would > get rid of one of the silliest parts of Elm. > > > > On Fri, Jun 17, 2016 at 7:38 AM, Max Goldstein <[email protected] > <javascript:>> wrote: > >> I think Ian makes some great points and Iargely agree with him. I like >> that Elm is actually less to learn than React, Ember, etc, once you factor >> in ES2015 and JSX/handlebars and all the other stuff. >> >> However, automatically derived JSON decoders are something I could >> potentially support. They seem to crop up a lot, and in application rather >> than library code (i.e. Random generators and Producers can hide the >> boilerplate behind a library but JSON can't be similarly carpeted over). >> There's also some precedent here with type alias of record types. I think a >> minimally obtrusive proposal would be no extra syntax, just some extra >> functions defined implicitly by a type alias. Example: >> >> type alias User = { name : String, id : Int } >> >> defines the type User and also the function User : String -> Int -> User. >> It's not a horrible idea to have it also define encodeUser : User -> >> Json.Value and decodeUser : Decoder User. If the type alias isn't JSON >> serializable, then nothing happens. If the programmer defines >> (en|de)codeUser herself, then the generated versions disappear. >> >> > > > > -- > There is NO FATE, we are the creators. > blog: http://damoc.ro/ > -- 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.
