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.
