> 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 <[email protected] > <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 <[email protected]> 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 <[email protected]> > 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]. > >>>>> 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. > >> > >> > > -- > > 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.
