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

[Noah Hall]

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

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

[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 
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 

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

[Maxime Dantec]

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