Re: [elm-discuss] Re: Feature Request: Code Generation/ Macro System

2016-06-12 Thread Isaac Shapira
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 shoul

Re: [elm-discuss] Re: Feature Request: Code Generation/ Macro System

2016-06-12 Thread Isaac Shapira
t 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,

[elm-discuss] Re: Feature Request: Code Generation/ Macro System

2016-06-11 Thread Isaac Shapira
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

[elm-discuss] Re: Feature Request: Code Generation/ Macro System

2016-06-11 Thread Isaac Shapira
erator 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: &

[elm-discuss] Feature Request: Code Generation/ Macro System

2016-06-11 Thread Isaac Shapira
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