AST macros
Don Clugston
dac at nospam.com.au
Mon Mar 19 04:17:13 PDT 2007
Walter Bright wrote:
> Marcin Kuszczak wrote:
> > Walter Bright wrote:
> >> It's pretty simple:
> >>
> >> macro foo(args)
> >> {
> >> ...syntax that gets inserted...
> >> }
> >>
> >> and the args and syntax is evaluated in the context of the
> invocation of
> >> the macro, not the definition of the macro. You'll be able to do things
> >> like:
> >>
> >> macro print(arg)
> >> {
> >> writefln(__FILE__, __LINE__, arg);
> >> }
> >>
> >> which get the file and line in the right context. There's no way to do
> >> that right now.
This looks great already. However, I don't see any specific "abstract
syntax tree" syntax in this. Is that still a work-in-progress?
An observation:
My version of vector operation expression templates is mostly working
now, using the existing mixins. It deals with ASTs by constructing a
string representing the operations to be performed, and a tuple
containing all of the parameters. The operations string is of the form
"g+=((a+b)*c)+((d*e)+f)", where a, b, c... correspond to T[0], T[1],
T[2]... of the tuple T.
A compile-time function converts the string into postfix, and then
another CFTE function converts that into optimised x87 asm, which is
mixed in.
Unexpectedly, I found that it's actually very nice to have flattened
tuples. If an AST could recognise that two parameters are the same, it
could avoid duplication in the tuple, something that a tree can't easily do:
eg somevec+= othervec + somevec*3;
could become "T[1]+=T[0]+(T[1]*3)" which allows better code generation
in the final stage.
It may be useful to separate the tree from the values in this way --
it's not clear to me that (for D) it's desirable to have function calls
and parameters mixed together in the way that Lisp does.
More information about the Digitalmars-d
mailing list