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, generating ord and non-default toString are good use cases of where Elm the language is missing things _right now_, and therefore it makes sense to implement "macros" 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. On Sun, Jun 12, 2016 at 5:44 PM, Isaac Shapira <[email protected]> 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]. > 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.
