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

[Don]

Yigal Chripun wrote:
> 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.

Ah, OK. My cursory glance at Nemerle just screamed "hack". But first 
impressions can be misleading.
No doubt as a C-family language, they have some useful ideas.
But if Christopher's analysis is correct, the "macro" bit is different 
to the "plugin" bit. I think allowing the ASTs to be _modified_ by 
plugins is the path to madness, but a read-only ABI is OK (it's hard to 
see how compile-time reflection is possible without creating some kind 
of API).