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

[Ary Borenszweig]

Jarrett Billingsley wrote:
> On Thu, Oct 8, 2009 at 11:25 AM, Don <nospam at nospam.com> 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.
> 
> All the Nemerle *implementation* is doing differently here is having
> you precompile the functions that are to be executed at compile-time.
> That's it. The resultant semantics are utterly the same. You are
> running code at compile-time, it doesn't matter if that code is
> running on the hardware or in a VM in the compiler.
> 
>>> 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.
> 
> And Nemerle's macros are *hard* to explain? They're a function that
> executes at compile time. Oh, wait! That's exactly the same as CTFE.
> 
>>> 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!
> 
> I'm not talking about me. I'm talking about you. I don't know how you
> can trash a language with macros that were designed *from the bottom
> up* to be used as such and which are treated as first-class citizens,
> while not admitting the hilariously ad-hoc nature of a language where
> macros fall out as a consequence of a number of other, ill-defined
> poorly-implemented unorthogonal features.
> 
> Sigh, I'm done.

I agree with Jarrett here. And also seeing how some things are 
implemented in D using CTFE and .stringof and it's parsing is very 
complex to understand. I mean, I read the code and it's very hard for me 
to understand what's going on. Specially because it's mostly all of the 
time parsing strings and extracting information which I don't know in 
what format it comes in the first place, it's just guess and work around it.