How about macro == symbol for mixin statement? [was Re: Member

[Yigal Chripun]

Don Wrote:

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

I agree that there should be a source code equivalent for macros - otherwise it probably would be hard to debug. But I think we agree that at least a read only API would be very useful, much better than the current bag-o-hacks and without the risks. 

I know the Nemerle devs are working on improving their Macro system implementation. I'll ask in their NG about this issue.