> Larry Wall wrote:
> [snip]
> > Nope.  $x and $p are syntax trees.
> 
> <blink>
> 
> Macros are passed syntax trees as arguments, but return coderefs?
> 
> That's... odd.
> 
> I would expect that a macro would be expected to *return* a syntax
> tree... which could then undergo (more) macro-expansion.

Keep in mind, a macro can return a lot of things to get a lot of
different behavior.  It can return a string which will be inserted in
the input stream in place of the macro call; it can return a closure
which will be inserted into the generated code at that point.  Along
the same lines, you can return a syntax tree to be inserted into the,
um, syntax tree at that point.

Perhaps with C<template>, as Larry mentioned earlier (though I'm not
sure that he intended this meaning):

    template { $x + 1 }

Would return a syntax tree for $x + 1.  Obviously, the syntax tree
would have to be closure-like, because the string '$x' isn't enough to
represent this $x.  It would have to keep some sort of reference to
the lexical... or lexical table entry... or something.

And indeed, that would solve the macro recursion bit, if the
just-inserted syntax tree underwent more macro expansion.

Luke

> Sortof like how in lisp, a macro recieves lists as arguments (those
> lists being un-evaluated code) and then returns a list, which then has
> more macro expansion done on it, and then gets parsed and evaluated.
> 
> -- 
> $a=24;split//,240513;s/\B/ => /for@@=qw(ac ab bc ba cb ca
> );{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print "[EMAIL PROTECTED]
> ]\n";((6<=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))&&redo;}

Reply via email to