> 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;}