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 <he...@warry.fr > <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 elm-discuss...@googlegroups.com <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 elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
