System programming in D (Was: The God Language)

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Fri Dec 30 15:02:20 PST 2011


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




More information about the Digitalmars-d mailing list