: >[EMAIL PROTECTED] (Luke Palmer) writes:
: >
: >
: >>I would hope the former. However, what about this compile-time
: >>integral power macro[1]?
: >>
: >> macro power ($x, $p) {
: >> if $p > 0 {
: >> { $x * power($x, $p-1) }
: >> }
: >> else {
: >> { 1 }
: >> }
: >> }
Note that you have to explicitly return a closure, otherwise they look like
bare blocks. Which might accidentally do what you want, if $x knows how
to be a number, and any return value that's not a closure gets coerced to
string. But it wouldn't be doing what you think it's doing.
: >>That would hopefully turn:
: >>
: >> my $var = 10;
: >> print power $var, 4;
: >>
: >>Into
: >>
: >> print($var * $var * $var * $var * 1);
: >>
: Alex Burr wrote:
: >The complete answer to this would be partial evaluation. Partial
: >evaluators exist for langauges such as lisp, ML, and even C. See
: >http://www.dina.dk/~sestoft/pebook/pebook.html
I tend to think of it inside out from that, in terms of deferred
evaluation of the parts that are known to be still undefined.
Note that we can know how to parse a macro from its declaration even
before we know how to call its body, so we can tell easily when we
hit power() that it can parse but can't run yet.
: >A partial evaluator simplifies a function with respect to some of its
: >inputs, if possible. This can be quite powerful: If P is a partial
: >evaluator, I an interpreter, and C some code, the P(I,C) compiles C
: >(in a rudimentary sort of way) and P(P,I) produces a compiler. But
: >code has to be written with an eye to making it possible to simplify it,
: >otherwise you just get the original code back.
: >
: >In theory you could write one as a perl6 macro, although it would be
: >more convenient if there was someway of obtaining the syntax tree of a
: >previously defined function other than quoting it (unless I've missed
: >that?).
: >But I confidently predict that no-one with write a useful partial
: >evaluator for perl6. The language is simply too big.
On Fri, Sep 12, 2003 at 12:49:47PM -0700, Mark A. Biggar wrote:
: As it is currently defined the default "is parsed" trait includes
: evaluating the arguments before the marco is called, so the above
: macro doesn't do what you want with out adding some magic.
I don't think it evaluates unless you tell it to explicitly.
: One way to do what you want is to use a string returning macro with
: an "is parsed" trait that return the unevaluated args as strings and
: then concat up the string for the expression you want.
Shouldn't be a problem--the arguments are pattern match result objects
that can behave as strings if you want them to.
: Another possibility is a built-in trait orthoginal to "is parsed"
: that turns off argument evaluation and allow the args to be passed
: in as syntax trees, allowing the macro to built the syntax tree
: to be returned.
That's the default. You'd need to use .run or some such to execute
a chunk of syntax tree. Remember that the definition of eval($str)
is something like $str.parse.run. I suppose evalharder($str) would
be $str.parse.optimize_the_heck_out_of.run. :-)
: I imagine that by the time all is done there will be a whole set
: if trait definitions to make various types of macros easy to do.
: Which brings us back to the need for a way to bundle up a set of
: traits and give it a name.
If we work it right, that's just called a "module". I think of traits
as funny class definitions, and we're already planning to be able to
bundle related classes in a module. Could go so far as to have derived
modules that can retarget an entire collection of classes in parallel.
Larry
