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
Just to throw my two cents in, I'd want to be pretty conservative about any
macro/code gen system if there is an official one at all. One of the things I
love about Elm is that the restrictive nature of the language makes code very
easy to follow and understand, and naturally causes libraries
FWIW I've already turned json-to-elm into kind-of-macros for my own
personal usage along with a couple of other things.
I don't think that elmx is a compelling use case though. I think it's
best to leave that stuff to the react people. Things like decoders,
encoders, reducing boilerplate,
Let me make the scenarios I mentioned more clear. I'm not advocating for a
macro language, I'm advocating for a means of doing code generation that is
consistent and maintainable. Producers could be solved with code
generation, elmx could be replaced with code generation (I don't think it
I also think that it should not be in the core. And I'd argue, that this
thread is about polling the community about the idea :)
I have a tiny beginning of an Elm parser written
using https://github.com/Bogdanp/elm-combine (awesome lib!!) that I could
push once it compiles (^^).
On Sunday,
Do you have a deadline? Ok. Then write a little external code generator, or
fork the compiler and make your own technical decisions *without* any
expectation that it will get merged into upstream.
Now, are you simply trying to improve the language? You really want some
kind of macro system
On Saturday, June 11, 2016 at 10:29:05 PM UTC+2, Joey Eremondi wrote:
>
> elm-package could require package names to be at a certain "distance" from
>> one another
>
>
> That still doesn't resolve the problem of running arbitrary code. If our
> community gets big enough that I don't know and
>
> elm-package could require package names to be at a certain "distance" from
> one another
That still doesn't resolve the problem of running arbitrary code. If our
community gets big enough that I don't know and trust every author from
this mailing list, we need a way to stop people from being
Some things to consider:
*Templating and Macros are Separate Issues*
We can decide that we want to allow for macros for brief code generation,
without making a separate templating language.
I'm with Max on the sentiment that having to learn a new language.
*Macros *need* to be type safe, but
