On Mon, 12 Jul 2010 20:00:12 -0400, pillsy <pillsb...@gmail.com> wrote:
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article:
On Mon, 12 Jul 2010 16:22:28 -0400, bearophile
<bearophileh...@lycos.com>
wrote:
[...]
> In my opinion the std.bitmanip.bitfields souce code is already past
the
> decency limit for string mixins, and I hope they will be replaced by
> something better.
How would AST macros make std.bitmanip.bitfields easier to understand?
I
have never seen it before, and I understood it after a couple minutes
reading. I bet the AST version would be actually harder to understand.
That's not such a great example. The problems will start piling up when
you have more complicated arguments.
Say you want your macro to look like it has an argument list with two
entries, called like
foo(x, y)
which acts like a string mixin, and receives "x, y" as the argument
string. Then you split at the comma, and
you're fine.
This isn't exactly what I meant to do with macros. What I wanted was for
the commas to separate the expressions, and pass those expressions via
stringification. It isn't a fully fleshed out idea, but here is what I
was thinking:
macro foo(arg1, arg2) mixin("$arg1 + $arg2;") // $ inside string
references parameter, just a possibility
foo(x, y); // translates to mixin("x + y;");
These are just ideas, perhaps there are issues with them, but I think we
can come up with reasonable rules that allow a lot of flexibility, and at
the same time, allow mixins to be masked as normal expressions, resulting
in greater usability in generic code, and much more beautiful code.
You go on with your day, and the next thing you know someone is
complaining that your foo macro
doesn't work because it chokes on
foo(bar(a, b), c)
and
foo("d, e", f)
By the time you deal with all the possibilities, you'll have written
most of a parser. That parser has gotta parse
the text into *something*, and it'll probably be a tree.
Or, you say "foo isn't meant to deal with that input" :)
I don't see people complaining that bitfields doesn't accept such various
strings as arguments...
There's no reason you can't use library functions to parse strings
containing D code into that tree; indeed,
having access to such functions in the standard library would be useful
in all sorts of ways. RIght now D is only
a couple steps away from where it would need to be in order to allow
people to build a really useful macro
system in libraries.
I think a full parser would not hurt, but most of the time, you just want
to use the expressions in generating some code. Pulling apart an
expression and reassmbling it can solve some problems, but the majority of
the reason to need macros is to generate code, not to read it and rewrite
it.
-Steve
