DIP 50 - AST macros
Jacob Carlborg
doob at me.com
Wed Nov 13 04:47:21 PST 2013
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
More information about the Digitalmars-d
mailing list