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

[Bill Baxter]

On Thu, Oct 8, 2009 at 1:06 AM, Don <nospam at nospam.com> wrote:
> Jarrett Billingsley wrote:
>>
>> On Wed, Oct 7, 2009 at 11:21 AM, Don <nospam at nospam.com> wrote:
>>>
>>> Steven Schveighoffer wrote:
>>>>
>>>> On Wed, 07 Oct 2009 09:17:59 -0400, Jarrett Billingsley
>>>> <jarrett.billingsley at gmail.com> wrote:
>>>>
>>>>> It's also insanely kludgy and ugly. Bleh.
>>>
>>> Ugly, yes. Kludgy, I don't think so. It's only a syntax issue. The basic
>>> concept of passing meta-code to the compiler in the form of raw text is
>>> simple:
>>>
>>> mixin() if you want to insert something into the parse step.
>>>  is(typeof()) if you want to catch it again after the syntax pass.
>>>  stringof if you want to catch it again after the semantic pass.
>>>
>>> And that's all. The syntax is ugly, but the semantics are beautifully
>>> elegant.
>>
>> It'd be nice if they actually worked. is(typeof()) fails for *any*
>> error, and it eats those errors too, so if your code fails to compile
>> for some reason other than the one you're testing for, welp, good luck
>> figuring that out. And don't even get me started on .stringof.
>>
>> Also, see my post on the "get template and its instantiation
>> parameters" thread for my detailed opinion on them.
>>
>>> By contrast, something like Nemerle macros are a kludge. The idea of
>>> providing a 'hook' into the compiler is a horrible hack. It exposes all
>>> kinds of compiler internals. Yes, it has nicer syntax.
>>
>> I.. don't even know how to begin to respond to that.
>
> Have you read the Nemerle extended macro tutorial? The compiler's internal
> structures are completely exposed. That's a hack.

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.

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?

--bb