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

[Yigal Chripun]

On 08/10/2009 17:25, Don wrote:
> Jarrett Billingsley wrote:
>> On Thu, Oct 8, 2009 at 4:00 AM, Don <nospam at nospam.com> 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:
>>>
>>> http://nemerle.org/Macros_-_extended_course._Part_2
>>>
>>> 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:
<quote>
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.
</quote>


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