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

Yigal Chripun yigal100 at
Fri Oct 9 12:37:46 PDT 2009

On 08/10/2009 17:25, Don wrote:
> Jarrett Billingsley wrote:
>> On Thu, Oct 8, 2009 at 4:00 AM, Don <nospam at> wrote:
>>>> So it looks to me like the mechanics of it are basically identical.
>>>> Just Nemerle's syntax is nicer.
>>> Only with trivial examples. With more complicated examples they look
>>> less
>>> identical. I'm basing my views on pages like this:
>>> Unless I'm totally misunderstanding this, it looks to me as though
>>> Nemerle
>>> macros are implemented as compiler plugins.
>>> All the advanced facilities are obtained by exposing the compiler's API!
>> Well they're not.. "plugins" per se as much as "compiled modules."
>> Okay yes that's basically a plugin :P But it's not that different from
>> D, where you use compile-time executed functions to do the same sorts
>> of things. It's just that you precompile those functions instead of
>> having the compiler "compile" them on every compilation.
> No. CTFE is simply taking constant-folding to its logical conclusion.
>> But really, I don't see how this is significantly different from
>> hooking into the D compiler's internals with __traits, .stringof,
>> .mangleof and the like. So it uses an object-oriented API to access
>> those things instead of ad-hoc hacks. And?
> The thing I think is elegant about D's approach, ugly as the syntax
> currently is, is the complete separation of the lex - parse - semantic -
> codegen phases. And I think CTFE is fantastic (and I plan to fix it so
> it works properly). Think about how easy it is to explain.
What about Nemerle's macro system design (I'm not talking about their 
specific implementation of it) conflicts with D's complete separation of 
lex -> parse -> semantic phases?
The phases can still be completely separate *but* extensible by the 
macro system.

BTW, regarding this design aspect of DMD and D
The dragon book (second edition) says on page 966:
Object-Oriented Versus Phase-Oriented
with an object oriented approach, all the code for a construct is 
collected in the class for the construct. Alternatively, with a 
phase-oriented approach the code is grouped by phase so a type checking 
procedure would have a case for each construct and a code generation 
procedure would have a case for each construct, and so on.
the tradeoff is that an object-oriented approach makes it easier to 
change or add a construct, such as "for" statements, and a 
phase-oriented approach makes it easier to change or add a phase, such 
as type checking.

> I'm not a fan of is(typeof()) .stringof and __traits in their current
> form. They are hackish indeed, and weren't originally intended for macro
> development. (Actually .stringof isn't hackish, just buggy and
> unspecified). BUT they demonstrate the benefit of the seperate
> compilation phases. The fundamentals are strong.
>  > I don't know how you can trash Nemerle's approach while leaving D's
> unmentioned.
> What do you mean, 'unmentioned'? Hey, you started this by trashing D's
> approach!

More information about the Digitalmars-d-learn mailing list