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

[Christopher Wright]

Bill Baxter wrote:
> It seems macros are implemented as compiler extensions.  You compile
> your macros into DLLs first, that then get loaded into the compiler as
> plugins.  On the plus side, doing things that way you really do have
> access to any API you need at compile-time, using the same syntax as
> run-time.  All of .NET can be used at compile-time in your macros.  No
> more "can't CTFE that" gotchas.
> 
> But it does raise security concerns.  I wonder if they have some way
> to prevent macros from running malicious code.  I guess you better run
> your web-based compiler service in a tightly partitioned VM.

C# has security levels. If you run the Nemerle compiler in low trust 
mode, fewer bad things can happen.

> Overall it seems pretty nifty to me, really.  Giving macros access to
> an actual compiler API seems less hackish than throwing in a
> smattering of diverse functionality under the heading of __traits.
> And less prone to gotchas than trying to create a separate
> compile-time D interpreter that runs inside the D compiler.
> 
> What do you see as the down sides?  Just that some rogue macro might
> mess up the AST?

It makes macros highly compiler-specific, or requires the compiler's AST 
to be part of the language.

Nemerle took the nuclear option, and its macros are all-powerful. That's 
a reasonable way of doing things. I'd be happy with a more restricted 
system that's easier to standardize, especially if it got rid of all the 
hacky string manipulation in current D metaprogramming. (Seriously, even 
__traits returns string arrays for a lot of stuff. It's ridiculous.)