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, June 12, 2016 at 3:28:53 AM UTC+2, John Mayer wrote: > > 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 merged into upstream? Great. Realistically, how this > is going to play out: > > Build out a taxonomy of macro systems in, like, 10 major languages, > maintain some kind of matrix of pros and cons of different kinds of macro > systems, maybe come up with some stuff that no language does.* Do the > research. *Crucially, make sure that "no macro system" is also on that > list; try to open-mindedly come up with reasons why not to have a macro > system at all. Get people to help you with this research. Collect and > organize everything into one place for consumption. > > Present that to the Elm maintainers (Evan, obviously) and share it on the > mailing list. > > And then *wait*, because (based on his track record) Evan is going to > mull it over for a while. IMO, he gets that privilege because he's our > BDFL. Throughout this process Evan's going to come down with a set of > principles that are consistent with the rest of the Greater Goals of Elm. > The choice of action will derive from those principles. > > > > > Obviously people want this. People want lots of things. Making it easy for > Evan maximizes the chances of something happening. > > On Sat, Jun 11, 2016 at 7:31 PM, Maxime Dantec <[email protected] > <javascript:>> wrote: > >> >> >> 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 trust every author from >>> this mailing list, we need a way to stop people from being malicious. >>> >> >> Ok, this is a good enough reason not to have it in the core, but this is >> not a reason not to do it at all. >> >> Plus, you assume that all elm code is only ment to be running in the >> browser. But it already run on node with tests or in the repl, and I'm >> expecting a lot of people starting to release node-elm-packages soon. It'll >> just fell into the whitelist processus, as it always should when it comes >> to native code. >> >> -- >> 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] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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.
