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

[Yigal Chripun]

On 10/10/2009 10:50, Don wrote:
> Yigal Chripun wrote:
>> On 10/10/2009 00:36, Christopher Wright wrote:
>>> Yigal Chripun wrote:
>>>> On 09/10/2009 00:38, Christopher Wright wrote:
>>>>> It makes macros highly compiler-specific, or requires the
>>>>> compiler's AST
>>>>> to be part of the language.
>>>>>
>>>>> Nemerle took the nuclear option, and its macros are all-powerful.
>>>>> That's
>>>>> a reasonable way of doing things. I'd be happy with a more restricted
>>>>> system that's easier to standardize, especially if it got rid of
>>>>> all the
>>>>> hacky string manipulation in current D metaprogramming. (Seriously,
>>>>> even
>>>>> __traits returns string arrays for a lot of stuff. It's ridiculous.)
>>>>
>>>> It doesn't have to be compiler specific. all is needed is a
>>>> standardized API to the compiler.
>>>
>>> Right. It adds something huge that's normally compiler-specific to the
>>> language. This makes me uncomfortable. It greatly increases the
>>> difficulty of implementation.
>>>
>> I disagree - a properly designed compiler will have such an API anyway.
>
> Not if you have compilers from different vendors. And that's one of the
> key problems with making such an API part of language -- the potential
> for vendor lock-in.

if each compiler has its own API than you're correct but what I was 
talking about was a standard API that is part of the stdlib which the 
different vendors need to implement in order to be considered compliant 
to the language spec. the compiler internals need not be identical only 
the API as defined in the spec.

>
>>>> What's so hackish about that?
>>>
>>> Reread. Current D metaprogramming is hackish. Nemerle's isn't.
>>
>> I was referring to what Don said that providing a hook into the
>> compiler is hackish.
>
> I stand by that.
> Look, I was Forth guy back in the day. Forth and Lisp both have
> hack-free macros. Particularly in the case of Forth, the language is
> largely defined in the library; you can even make the case that the
> compiler is part of the library. So there's no problem with the library
> extending the language.
> But in the case of Nemerle, it's a conventional compiler with hooks for
> library code.

I don't know how deep you looked into Nemerle, but from my understanding 
that description is false. Nemerle is much closer to your description of 
Forth than you'd think.
Nemerle supports syntax extensions and parts of the language are already 
implemented as macros.
They are now considering to generalize this construct further so they 
could implement more of Nemerle as Macros.

>
> I just feel that Nermele's approach is diametrically opposed to Forth/Lisp.
> It's personal opinion. To me, that looks like a hack.
>
> To make one thing clear:
> D's compile-time reflection is a hack. And that makes most current 'D
> macros' hackish. I just feel that most of the problems lie on the
> reflection side.