How about macro == symbol for mixin statement? [was Re: Member functions C to D]

Don nospam at nospam.com
Wed Oct 14 01:12:01 PDT 2009


Yigal Chripun wrote:
> On 12/10/2009 10:47, Don wrote:
>>
>> Ah, OK. My cursory glance at Nemerle just screamed "hack". But first
>> impressions can be misleading.
>> No doubt as a C-family language, they have some useful ideas.
>> But if Christopher's analysis is correct, the "macro" bit is different
>> to the "plugin" bit. I think allowing the ASTs to be _modified_ by
>> plugins is the path to madness, but a read-only ABI is OK (it's hard to
>> see how compile-time reflection is possible without creating some kind
>> of API).
>>
> 
> modifying the AST is dangerous but how would you do things like making a 
> class implement an interface without modifying the list of interfaces 
> the class implements ?
> 
> [serialize]
> class Foo {...}
> 
> the Nemerle macro above transform this into:
> 
> class Foo : Serializable { ... }
> 
> what would be your design for this?

I don't think it should be done that way. Either it should be intrusive 
(eg, require you to derive from Serializable), or else entirely external 
(and operate via reflection). Eg, possibly by declaring 
Serializable!(Foo) after the definition of Foo.
It's an excellent question though, we might need some language changes 
to get a good solution. But I think it's very important to enforce that 
the only way to modify the AST is indirect, through code.

One of the strengths I see of the string mixins, despite their syntactic 
ugliness, is that metaprogramming transformations are only ever syntax 
sugar: there is _always_ a source-code equivalent; moreover, it's 
trivially available, simply by expanding all of the mixins (and Descent 
will show it to you). It's not clear to me that that remains true if you 
can manipulate the AST directly. Of course, if you allow direct access 
to the AST, you have unlimited power. Capturing as much of the power as 
possible, without the danger, is the challenge.




More information about the Digitalmars-d-learn mailing list