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

[Jarrett Billingsley]

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.