On 2013-11-13 09:15, luka8088 wrote:
I took a look at it as here is my conclusion for now:
Statement and attribute macro examples look great. But I don't like Linq
example. I don't think code like the following should be allowed.
I'm not a fan of the Linq example either. Or rather if I put it like
this. I think the Linq example is quite a good example what can be done
with AST macros. But I don't think it's a good fit in D.
query {
from element in array
where element > 2
add element to data
}
From my point of view this whole idea is great as it makes it easier
what is already possible. For example, with current behavior if I wanted
to write.
foo {
writeln("foo");
writeln("foo again");
}
I would have to write:
mixin(foo!(q{
writeln("foo");
writeln("foo again");
}));
So the proposed behavior looks much nicer, and I agree with it as the
content of foo block is actually written in D and I think whoever is
reading it would be comfortable with it.
However, for other, non-D syntax-es I would prefer something like:
Well, the macros in the DIP only supports the D syntax. The macros work
at the semantic level. You cannot create new syntax but you can give
existing syntax new meaning. Compared with current D, macros need to lex
and parse correctly. But they don't need to be semantically correct.
That's the same thing as with templates, they can be semantically
invalid as long as they're not instantiated.
The Linq example is lexically correct. I'm not sure if the parser will
reject it or not.
query q{
from element in array
where element > 2
add element to data
}
Which can be handled by:
macro query (Context context, string dsl) {
return domainSpecificLanguageToD(dsl);
}
This in terms is already possible by writing the following, it only
allows to be written in a more readable way. And the q{ ... } notation
clearly points out that there is something special going on. Also by
passing such content as string user can implement custom (or call one of
the predefined) tokenizer/lexer/parser.
mixin(query!(q{
from element in array
where element > 2
add element to data
}));
I also don't like the <[ ... ]> syntax because:
1. Like others have said, it looks very foreign.
2. I don't think there is a need to add a new syntax.
As it says in the DIP, this is one suggestion of the syntax, if new
syntax is needed at all. It's just easier to show examples like that
than building a complete AST with function calls.
As you can see I have an alternative that doesn't require new syntax:
http://wiki.dlang.org/DIP50#The_AST_Macro
Instead of "<[ a + b ]>" you would do "ast(a + b)" or "ast { a + b }".
I think that string concatenation is enough (at least for now), and if
you want another syntax for templates you can write a macro for that.
Strings are far from enough. Then you have missed the whole idea. It's
not supposed to be syntax sugar for string mixins.
--
/Jacob Carlborg
