On Thu, Oct 8, 2009 at 1:06 AM, Don <nos...@nospam.com> wrote: > Jarrett Billingsley wrote: >> >> On Wed, Oct 7, 2009 at 11:21 AM, Don <nos...@nospam.com> wrote: >>> >>> Steven Schveighoffer wrote: >>>> >>>> On Wed, 07 Oct 2009 09:17:59 -0400, Jarrett Billingsley >>>> <jarrett.billings...@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