System programming in D (Was: The God Language)

[Timon Gehr]

On 12/31/2011 12:02 AM, Andrei Alexandrescu wrote:
> On 12/30/11 3:51 PM, Timon Gehr wrote:
>> On 12/30/2011 09:51 PM, Andrei Alexandrescu wrote:
>>> On 12/30/11 12:10 PM, Walter Bright wrote:
>>>> On 12/30/2011 4:05 AM, Timon Gehr wrote:
>>>>> It certainly does. That is how all my code generation looks like. The
>>>>> fact that
>>>>> I am using string mixins to solve some problems shows that those are
>>>>> not
>>>>> 'problems in D string mixins'.
>>>>
>>>> I your solution to parameterized strings is very nice. Can you write a
>>>> brief article about it? This should be more widely known.
>>>
>>> The idea is good, but nonhygienic: the macro's expansion picks up
>>> symbols from the expansion context.
>>>
>>
>> What the template 'X' currently achieves is an improvement in syntax:
>>
>> string generated = "foo!\""~x~"\"(\""~bar(y)~"\")";
>>
>> vs
>>
>> string generated = mixin(X!q{
>> foo!"@(x)"("@(bar(y))")
>> });
>
> I understand that. But the whole system must be redesigned. Quoting from
> my email (please let's continue here so as to avoid duplication):
>
> The macro facility should be very simple: any compile-time string can be
> a macro "body".
>
> The key is the expansion facility, which replaces parameter placeholders
> (e.g. in the simplest instance $1, $2 etc) with actual parameters. This
> is missing. Also, there must be expansion of other already-defined macro
> names. This is already present.
>
> The library has a simple interface:
>
> enum myMacro = q{... $1 $2 $(anotherMacro($1))... };
>
> // To mixin
> mixin(expand(myMacro, "argument one", "argument two"));
>
>
> Andrei
>
>

I understand, but compared to how I solved the issue

1. it invents an (arguably inferior) parameter passing system, even 
though there is one in the language.
2. it picks up all symbols used in $(...) from the caller's context 
rather than the callee's context and there is no way to get rid of that 
default, because the macro is unscoped.