[elm-discuss] Feature Request: Code Generation/ Macro System
Continuing the discussion started here: https://github.com/elm-lang/elm-compiler/issues/1413 -- 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.
[elm-discuss] Re: Feature Request: Code Generation/ Macro System
@mgold <https://github.com/mgold> If you are suggesting that tedious to write elm code should be addressed by a distributed series of independent browser based online code generators, I'm going to say that's not a real solution. I don't want to go to a different set of browser bookmarks for different common derivable code scenarios. Nor do I want code generation outside of my build process. If you are suggesting using things like json-to-elm inside of a build process, then we are potentially in some kind of module loader hell. json-to-elm looks like it uses python for generation, so now python is in the stack, and there is no consistent standard for how these distributed set of tools should work. If we wish to address 10+ boilerplate heavy scenarios, we now have to custom install and rig together disparate apis of these different generation tool into our build. And once all that is working, essentially we just invented fraken macros, where macro code is separate outside of .elm files. A proper macro system seems like the only solution to me atm. That's not to say there is only one way of going about it. One way that might address the "One Language" and maintainability concern, is to have macros that are outside of Elm. As in elm-make provides a facility to pipe code into an external process for expansion. Then type checks the expanded code. This could also mean that elm-package now needs the ability to let code generator authors package an executable with any surrounding elm files. I feel this could also discourage the abuse that can come from macros, as there are more barriers to set up the external code gen process and wire it in. On Saturday, June 11, 2016 at 1:26:55 PM UTC-6, Isaac Shapira wrote: > > Continuing the discussion started here: > > https://github.com/elm-lang/elm-compiler/issues/1413 > -- 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.
[elm-discuss] Re: Feature Request: Code Generation/ Macro System
@Maxime Call it what you will. Pre-processor, Macro, Template, they have different meanings but solve the same problem, generate code rather than write tedious code when possible. Regardless it going to mean some edits to the Haskell side, since it needs some kind of compile time support, as well as package management support. @Joey I understand the concern, but I think its worth the risk. Thank and typo-squatting seems like it could be resolved another way. elm-package could require package names to be at a certain "distance" from one another. That and since user names are required in the package name, the risk is much lower. On Saturday, June 11, 2016 at 2:03:21 PM UTC-6, Maxime Dantec wrote: > > Jumping in ! I said in the github issue that I was in favour of macros, > but macros imply hacking the (haskell) core of the compiler. Wouldn't > preprocessor be a better description ? > > On Saturday, June 11, 2016 at 9:39:28 PM UTC+2, Isaac Shapira wrote: >> >> @mgold <https://github.com/mgold> If you are suggesting that tedious to >> write elm code should be addressed by a distributed series of independent >> browser based online code generators, I'm going to say that's not a real >> solution. I don't want to go to a different set of browser bookmarks for >> different common derivable code scenarios. Nor do I want code generation >> outside of my build process. >> >> If you are suggesting using things like json-to-elm inside of a build >> process, then we are potentially in some kind of module loader hell. >> json-to-elm looks like it uses python for generation, so now python is >> in the stack, and there is no consistent standard for how these distributed >> set of tools should work. If we wish to address 10+ boilerplate heavy >> scenarios, we now have to custom install and rig together disparate apis of >> these different generation tool into our build. And once all that is >> working, essentially we just invented fraken macros, where macro code is >> separate outside of .elm files. >> >> A proper macro system seems like the only solution to me atm. That's not >> to say there is only one way of going about it. >> >> One way that might address the "One Language" and maintainability >> concern, is to have macros that are outside of Elm. As in elm-make provides >> a facility to pipe code into an external process for expansion. Then type >> checks the expanded code. This could also mean that elm-package now needs >> the ability to let code generator authors package an executable with any >> surrounding elm files. I feel this could also discourage the abuse that can >> come from macros, as there are more barriers to set up the external code >> gen process and wire it in. >> >> On Saturday, June 11, 2016 at 1:26:55 PM UTC-6, Isaac Shapira wrote: >>> >>> Continuing the discussion started here: >>> >>> https://github.com/elm-lang/elm-compiler/issues/1413 >>> >> -- 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.
Re: [elm-discuss] Re: Feature Request: Code Generation/ Macro System
Fair enough. However I still think "distance" could solve the typo problem. As in evanzc/elm-graphics would not be allowed as its too "close" to an existing package name. On Saturday, June 11, 2016 at 2:29:05 PM UTC-6, 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. > Elm is about reliability. We're trying to be better than JavaScript, so > the security needs to be airtight. > > Usernames increase the risk, I'd say. Someone could make > evanzc/elm-graphics, and the typo is a lot harder to spot at first glance. > And by your method, if evanzc was a legitimate elm developer, they'd need > to make a whole new github account just to make a package. > > The name collisions aren't the problem. Running arbitrary untrusted code > at compile-time is. We can avoid this, but it needs to be central to the > design, not an afterthought. > > On Sat, Jun 11, 2016 at 1:18 PM, Isaac Shapira > wrote: > >> @Maxime Call it what you will. Pre-processor, Macro, Template, they have >> different meanings but solve the same problem, generate code rather than >> write tedious code when possible. Regardless it going to mean some edits to >> the Haskell side, since it needs some kind of compile time support, as well >> as package management support. >> >> @Joey I understand the concern, but I think its worth the risk. Thank and >> typo-squatting seems like it could be resolved another way. elm-package >> could require package names to be at a certain "distance" from one another. >> That and since user names are required in the package name, the risk is >> much lower. >> >> >> On Saturday, June 11, 2016 at 2:03:21 PM UTC-6, Maxime Dantec wrote: >>> >>> Jumping in ! I said in the github issue that I was in favour of macros, >>> but macros imply hacking the (haskell) core of the compiler. Wouldn't >>> preprocessor be a better description ? >>> >>> On Saturday, June 11, 2016 at 9:39:28 PM UTC+2, Isaac Shapira wrote: >>>> >>>> @mgold <https://github.com/mgold> If you are suggesting that tedious >>>> to write elm code should be addressed by a distributed series of >>>> independent browser based online code generators, I'm going to say that's >>>> not a real solution. I don't want to go to a different set of browser >>>> bookmarks for different common derivable code scenarios. Nor do I want >>>> code >>>> generation outside of my build process. >>>> >>>> If you are suggesting using things like json-to-elm inside of a build >>>> process, then we are potentially in some kind of module loader hell. >>>> json-to-elm looks like it uses python for generation, so now python is >>>> in the stack, and there is no consistent standard for how these >>>> distributed >>>> set of tools should work. If we wish to address 10+ boilerplate heavy >>>> scenarios, we now have to custom install and rig together disparate apis >>>> of >>>> these different generation tool into our build. And once all that is >>>> working, essentially we just invented fraken macros, where macro code is >>>> separate outside of .elm files. >>>> >>>> A proper macro system seems like the only solution to me atm. That's >>>> not to say there is only one way of going about it. >>>> >>>> One way that might address the "One Language" and maintainability >>>> concern, is to have macros that are outside of Elm. As in elm-make >>>> provides >>>> a facility to pipe code into an external process for expansion. Then type >>>> checks the expanded code. This could also mean that elm-package now needs >>>> the ability to let code generator authors package an executable with any >>>> surrounding elm files. I feel this could also discourage the abuse that >>>> can >>>> come from macros, as there are more barriers to set up the external code >>>> gen process and wire it in. >>>> >>>> On Saturday, June 11, 2016 at 1:26:55 PM UTC-6, Isaac Shapira wrote: >>>>> >>>>> Continuing the discussion started here: >>>>> >>>>> https://github.com/elm-lang/elm-compiler/issues/1413 >>>>> >>>> -- >> 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [elm-discuss] Re: Feature Request: Code Generation/ Macro System
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 > 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 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-
