> or just editor plugins to generate that code for you. > *I don't think they're compelling use cases for macros as part of Elm > itself*. >
I agree. For example: as soon as you are generating union types, you are probably doing it wrong. > > > > On Sun, Jun 12, 2016 at 5:44 PM, Isaac Shapira <freshe...@gmail.com > <javascript:>> wrote: > > 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 should be > core > > language), boilerplate in update functions could be replaced with code > > generation (and I don't see another path here, since it involves pattern > > matching, see original example). > > > > On Sunday, June 12, 2016 at 10:16:59 AM UTC-6, Aaron VonderHaar wrote: > >> > >> If someone created a macro system, it would be interesting to see what > >> could be done with it. But I think that would be extremely > experimental. > >> I'm not convinced that having a macro system would lead to good > solutions > >> for the things it could be used to solve. > >> > >> Specific to this conversation, there were three features mentioned in > the > >> original github issue: > >> > >> - make it easy to generate quickcheck producers > >> - make `elmx` a core language feature > >> - reduce boilerplate in `update` functions > >> - other boilerplate scenearios > >> > >> I don't think a macro system is going to be a great solution for any of > >> those things. (For quickcheck producers, I think having quickcheck > >> automatically do that via native code, or having a general API for data > >> structure reflection would probably be better. For `elmx`, I > personally > >> don't think it should be in the core language. For `update` > boilerplate, I > >> think a good solution will need to be part of the core framework and > >> shouldn't depend on macros even if they existed. And for the > supposedly > >> large number of other boilerplate scenarios, let's take a look at them > and > >> see what they have in common that might be able to be solved more > simply > >> than by having a macro language.) > >> > >> In general, if someone wants to build an experimental macros system > just > >> to see what might come out of it, I think it would be great to see how > that > >> goes. But if we are talking about specific problems, we should focus > on > >> trying to solve those problems rather than assuming that macros would > solve > >> those problems. > >> > >> On Sun, Jun 12, 2016 at 3:58 AM, Maxime Dantec <he...@warry.fr> wrote: > >>> > >>> 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> > 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. > >>>>> 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...@googlegroups.com. > >>> 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...@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.
