On 11/10/2013 01:20 PM, Jacob Carlborg wrote:
> I've been thinking quite long of how AST macros could look like in D.
> I've been posting my vision of AST macros here in the newsgroup a couple
> of times already. I've now been asked to create a DIP out of it, so here
> it is:
>
> http://wiki.dlang.org/DIP50
>

For macros that generate macros, I think you need a way to escape the splicing and maybe define how splicing works in an inner quasi quote.

I guess you want <[ <[ $exp ]> ]> to turn into the ast <[ 1 ]>

Then if you wanted ast <[ <[ $exp ]> ]> with the splice associated with the inner quasi quote, you'd have to do something like

<[ <[ <[ \\\$exp ]> ]> ]>

maybe a way to associate a splice with a quasi quote?

<a[ <b[ <c[ $(a, exp) + $(b, exp) + $(c, exp)  ]> ]> ]>

a's exp is A
b's exp is B
c's exp is C

then splice the quasi quote N times:

1: ast <b[ <c[ A + $(b, exp) + $(c, exp) ]> ]>
2: ast <c[ A + B + $(c, exp) ]>
3: ast A + B + C

just dinking around here

On 2013-11-11 20:23, Ellery Newcomer wrote:

> For macros that generate macros, I think you need a way to escape the
> splicing and maybe define how splicing works in an inner quasi quote.
>
> I guess you want <[ <[ $exp ]> ]> to turn into the ast <[ 1 ]>
>
> Then if you wanted ast <[ <[ $exp ]> ]> with the splice associated with
> the inner quasi quote, you'd have to do something like
>
> <[ <[ <[ \\\$exp ]> ]> ]>
>
> maybe a way to associate a splice with a quasi quote?
>
> <a[ <b[ <c[ $(a, exp) + $(b, exp) + $(c, exp)  ]> ]> ]>
>
> a's exp is A
> b's exp is B
> c's exp is C
>
> then splice the quasi quote N times:
>
> 1: ast <b[ <c[ A + $(b, exp) + $(c, exp) ]> ]>
> 2: ast <c[ A + B + $(c, exp) ]>
> 3: ast A + B + C
>
> just dinking around here

This would require some thought.

-- 
/Jacob Carlborg

On Monday, 11 November 2013 at 19:23:21 UTC, Ellery Newcomer wrote:
> On 11/10/2013 01:20 PM, Jacob Carlborg wrote:
>> I've been thinking quite long of how AST macros could look like in D.
>> I've been posting my vision of AST macros here in the newsgroup a couple
>> of times already. I've now been asked to create a DIP out of it, so here
>> it is:
>>
>> http://wiki.dlang.org/DIP50
>>
>
> For macros that generate macros, I think you need a way to escape the splicing and maybe define how splicing works in an inner quasi quote.
>
> I guess you want <[ <[ $exp ]> ]> to turn into the ast <[ 1 ]>
>
> Then if you wanted ast <[ <[ $exp ]> ]> with the splice associated with the inner quasi quote, you'd have to do something like
>
> <[ <[ <[ \\\$exp ]> ]> ]>
>
> maybe a way to associate a splice with a quasi quote?
>
> <a[ <b[ <c[ $(a, exp) + $(b, exp) + $(c, exp)  ]> ]> ]>
>
> a's exp is A
> b's exp is B
> c's exp is C
>
> then splice the quasi quote N times:
>
> 1: ast <b[ <c[ A + $(b, exp) + $(c, exp) ]> ]>
> 2: ast <c[ A + B + $(c, exp) ]>
> 3: ast A + B + C
>
> just dinking around here

$ refers to the enclosing scope. so $$foo should refers to $foo in the enclosing scope. No need for special rule or label.

On 11/11/2013 05:47 PM, Dicebot wrote:
> On Monday, 11 November 2013 at 16:28:17 UTC, Timon Gehr wrote:
>> I don't agree. (The argument against implicit mixin features was a
>> complete lack of hygiene, not the mere possibility of accessing the
>> caller scope.)
>
> How would you expect it to be hygienic in any way if it has implicit
> outer scope access? Reasoning is pretty much the same as with mixins.

With mixins _every_ identifier is by _default_ inserted/looked up in the so-called 'outer scope', whereas declarations and normal symbol lookups within macros are hygienic by default. Macros are as much about reflection as about code generation. The trade-offs are simly not the same. Implicit outer scope access does not imply it behaves in a counter-intuitive manner. (It could just reflect some debug information after all, or perform some additional checks on the context for more safety, etc.) I will be really unhappy with any proposal that does not allow to interchange function calls with macro calls transparently, even though such a scheme allows more abusive code to be written as well. If in some code base macros should be clearly marked, a naming convention (eg. prefix macro names with 'macro') can be used. (Enforcing such a convention is trivial and amounts to eg. a few lines of additional code in a modified D front end.)

On 11/11/2013 10:23 PM, Timon Gehr wrote:
>  simly

simply

On 11/11/2013 12:06 PM, deadalnix wrote:
> On Monday, 11 November 2013 at 19:23:21 UTC, Ellery Newcomer wrote:
>> On 11/10/2013 01:20 PM, Jacob Carlborg wrote:
>>> I've been thinking quite long of how AST macros could look like in D.
>>> I've been posting my vision of AST macros here in the newsgroup a couple
>>> of times already. I've now been asked to create a DIP out of it, so here
>>> it is:
>>>
>>> http://wiki.dlang.org/DIP50
>>>
>>
>> For macros that generate macros, I think you need a way to escape the
>> splicing and maybe define how splicing works in an inner quasi quote.
>>
>> I guess you want <[ <[ $exp ]> ]> to turn into the ast <[ 1 ]>
>>
>> Then if you wanted ast <[ <[ $exp ]> ]> with the splice associated
>> with the inner quasi quote, you'd have to do something like
>>
>> <[ <[ <[ \\\$exp ]> ]> ]>
>>
>> maybe a way to associate a splice with a quasi quote?
>>
>> <a[ <b[ <c[ $(a, exp) + $(b, exp) + $(c, exp)  ]> ]> ]>
>>
>> a's exp is A
>> b's exp is B
>> c's exp is C
>>
>> then splice the quasi quote N times:
>>
>> 1: ast <b[ <c[ A + $(b, exp) + $(c, exp) ]> ]>
>> 2: ast <c[ A + B + $(c, exp) ]>
>> 3: ast A + B + C
>>
>> just dinking around here
>
> $ refers to the enclosing scope. so $$foo should refers to $foo in the
> enclosing scope. No need for special rule or label.

so if I have to splice my ast N times, then I have to generate M $'s depending on when I want it to expand?

On Monday, 11 November 2013 at 16:22:40 UTC, Timon Gehr wrote:
> On 11/11/2013 01:36 PM, Rikki Cattermole wrote:
>>
>> Yes outside of macros would be useful. For example code like this would
>> become redundant:
>> pragma(msg, "Support for x is not implemented on platform y");
>> static assert(0);
>>
>> Becoming:
>> pragma(error, "Support for x is not implemented on platform y");
>
> static assert(0, "Support for x is not implemented on platform y");

Hmm wasn't aware of that syntax. Needs an example I think on docs.
I will still work on pull request as the point of an assert and pragma message is different, atleast I believe.

On 11/10/13 11:46 PM, Jacob Carlborg wrote:
> On 2013-11-11 02:46, bearophile wrote:
>
>> It's also useful to take a look at what F# is doing:
>> http://tomasp.net/blog/2013/computation-zoo-padl/index.html
>
> I'll do that. I've been looking at several languages, mainly Scala. But
> I have not looked at F#.

There is significant regret about the way macros are defined in Scala. Probably not an example to follow.

Andrei

On Sunday, 10 November 2013 at 21:20:34 UTC, Jacob Carlborg wrote:
> I've been thinking quite long of how AST macros could look like in D. I've been posting my vision of AST macros here in the newsgroup a couple of times already. I've now been asked to create a DIP out of it, so here it is:
>
> http://wiki.dlang.org/DIP50

Just a quick comment related to the 2007 proposal:

http://youtu.be/FRfTk44nuWE?t=1h5m38s
Page 45: http://s3.amazonaws.com/dconf2007/WalterAndrei.pdf

Based on my read though, yours is more powerful. The 2007 proposal is basically the "Quasi-Quoting" portions of your proposal (which is such a small part of your proposal).

On Tuesday, 12 November 2013 at 02:37:03 UTC, Andrei Alexandrescu wrote:
> On 11/10/13 11:46 PM, Jacob Carlborg wrote:
>> On 2013-11-11 02:46, bearophile wrote:
>>
>>> It's also useful to take a look at what F# is doing:
>>> http://tomasp.net/blog/2013/computation-zoo-padl/index.html
>>
>> I'll do that. I've been looking at several languages, mainly Scala. But
>> I have not looked at F#.
>
> There is significant regret about the way macros are defined in Scala. Probably not an example to follow.
>

Do you have some article/documentation on that ?

BTW, scala implemented macros as a plugin called macro paradise, which allowed people to play with it without crippling the core language. We should probably introduce new features that way.