On 02/01/2013 04:54 PM, Jacob Carlborg wrote:
> On 2013-02-01 16:36, Timon Gehr wrote:
>
>> Analysis and rewriting.
>
> I'm just thinking an API similar to a reflection API. Something like:
>
> Ast!(Class) c;
>
> foreach (Ast!(Member) m ; c.members)
> {
>      // do something with each member
> }
>

Yes, that will work, as long as all necessary information is exposed.

> Sure it would be easier and better looking with pattern matching.
>

I take it you mean syntax sugar for pattern matching? AST macros have failed if they do not allow a decent library implementation of such functionality. :)

Timon Gehr:

> I take it you mean syntax sugar for pattern matching? AST macros have failed if they do not allow a decent library implementation of such functionality. :)

Maybe Jacob Carlborg is able to show what kind of syntax for pattern matching the macros are able to create (no need to actually implement it now).

That document about D macros could use a good list of possible usages (copying something from the Scala site is OK).

Bye,
bearophile

On 2013-02-01 18:53, bearophile wrote:

> That document about D macros could use a good list of possible usages
> (copying something from the Scala site is OK).

Yeah, more usage examples are always good.

-- 
/Jacob Carlborg

On 2013-02-01 16:55, bearophile wrote:
> Jacob Carlborg:
>
>> But to answer your question, no. It didn't cross my mind.
>
> OK. (I have asked because syntax costs, so it's good to use it as much
> as possible, if it doesn't lead to ambiguities).

Yes, that's why I was thinking if we could do like Scala and implement it as in library, as a macro.

> I meant something more like (the now closed) Treehydra:
> https://developer.mozilla.org/en-US/docs/Treehydra_Manual

Could you give a quick, simple and small example of how you would like it to work in pseudo code or D?

-- 
/Jacob Carlborg

The reflection they have added to Scala is sometimes used inside Scala macros:

http://lampwww.epfl.ch/~michelou/scala/scala-reflection.html

Bye,
bearophile

And then I suggest to put the incomplete proposal for the macros in Bugzilla o DWiki or even in a DEP.

Bye,
bearophile

On Saturday, 2 February 2013 at 11:12:18 UTC, bearophile wrote:
> And then I suggest to put the incomplete proposal for the macros in Bugzilla o DWiki or even in a DEP.

I'm planning to do that. I was going to work on it a bit more but now when it's already out in the wild I'll create a DIP.

BTW, it's called DIP, as in D Improvement Proposal, not DEP.

http://wiki.dlang.org/DIPs

--
/Jacob Carlborg

On 2013-02-02 00:58, bearophile wrote:
> The reflection they have added to Scala is sometimes used inside Scala
> macros:
>
> http://lampwww.epfl.ch/~michelou/scala/scala-reflection.html

"Sometimes", it's rather _required_ to basically do anything useful.

-- 
/Jacob Carlborg

seems like my original post regarding __ARGS__ was completely hijacked by the discussion on AST macros (however fruitful and interesting). I agree macros would solve this issue while providing a much more general solution, however, it's very unclear when that would be implemented, surely not anytime soon.

Is there any other feedback on introducing __ARGS__  (see first post) besides AST macros being better? It's much simpler implementation-wise.

Am 01.02.2013 12:24, schrieb Timon Gehr:
> On 02/01/2013 11:54 AM, Jacob Carlborg wrote:
>> ...
>>
>> Sounds like an ugly hack for AST macros. This is a proposal for AST
>> macros I've been working on. It's not finished but here it is:
>>
>> https://dl.dropbox.com/u/18386187/ast_macros.html
>>
>
> Make sure to include some way to pattern match on the syntax trees.
> (Otherwise we are back to manual parsing of the ast.toString() output.)
>

from the text

"...The first parameter of macro is always of the type Context..."

is then there a real need for context as an parameter - it semanticly similar to "this" in the class scope - i would prefer a "context" keyword inside of the macro scope