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

[Christopher Wright]

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. 
> Look at how Clang is designed - it's a modular compiler where each part 
> has its own library. you can combine its libs in different ways to 
> provide different options: a full command-line compiler, semantic 
> analysis for IDE, incremental builder for an IDE, etc..
> that design obviously requires APIs for the different components.
> 
> 
>>> 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.
>>
>>> many large modular systems do exactly that: eclipse, firefox, even the
>>> OS itself. Unix provides syscalls which *are* an API to the OS.
>>>
>>> a properly designed API doesn't have to expose internal implementation
>>> details.
>>>
>>> btw, in Nemerle they have syntax to compose/decompose AST specifically
>>> so they don't need to expose the internal structure of the AST.
>>
>> So they have a separate object model for the syntax tree that macros can
>> affect. This is what I would recommend for D.
> 
> What do you mean by object model?
> 
> they have a synax to manipulate AST:
> <[ some code ]>  would be parsed by the compiler as the AST of "some 
> code" and would be represented internally by the compiler specific AST 
> representation.

I looked up nemerle macros after this. There are a couple parts.

1. AST Mixins
It's a lot like string mixins with builtin string formatting and 
automatic conversion of arguments to their string form. Syntactic sugar 
on top of this. That's all that macros are. Yes, you can manipulate the 
AST, but at this stage, it's entirely opaque.

2. Compiler plugins
You can define a compiler module that does arbitrary things to the AST. 
Many modules will make use of macros. The Nemerle compiler might attempt 
to conflate plugins with macros, but if there were an alternate 
implementation of Nemerle, the difference would become very apparent 
very quickly.

AST mixins are sexy. Compiler plugins are also sexy[1], but targeted 
toward a much different audience. D could benefit from both, but the 
latter is far lower on the list than a decent compile-time reflection 
system. And of this, only compiler plugins have the issues that I 
mentioned earlier.


[1] Unless you're Richard Stallman. Onoz, someone could use a 
proprietary plugin with GCC!