@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.
