Larry Wall <[EMAIL PROTECTED]> writes:
>Nick Ing-Simmons writes:
>: >You really have to talk about overloading boolean context
>: >in general.
>:
>: Only if you are going to execute the result in the normal perl realm.
>: Consider using the perl parser to build a parse tree - e.g. one to
>: read perl5 and write perl 6. This works for all expressions except
>: &&, || and ?: because perl5 cannot overload those - so
>:
>: $c = ($a && &b) ? $d : $e;
>:
>: calls the bool-ness of $a and in the defered execution mode of a translator
>: it wants to return not true/false but "it depends on what $a is at run-time".
>: It cannot do that and is not passed $b so cannot return
>
>I think using overloading to write a parser is going to be a relic of
>Perl 5's limitations, not Perl 6's.
I am _NOT_ using overloading to write a parser.
Parse::Yapp is just fine for writing parsers. I am trying to re-use
a parser that already exists - perl5's parser.
I am using overloading to get at the parse "tree" that the _existing_ parser
has produced.
So I can get at perly.y's :
term : ...
| '!' term
| term ADDOP term
etc. but NOT
| term ANDAND term
| term OROR term
| term '?' term ':' term
;
I can get at the former because overload maps via newBINOP/newUNOP
just fine, I cannot get at latter group because newLOGOP/newCONDOP
don't do overloading.
What _really_ want to do is a dynamically scoped peep-hole "optimize"
(actually a rewrite) of the op tree - written in perl.
But I can't do that, so I fake it by having
sub construct (&) { ... }
and then
construct {
# expression(s) here
}
and have construct() "call" the ops with the overload stuff returning a tree.
These days I suppose one could use B:: to poke about in the CV
>
>Larry
--
Nick Ing-Simmons <[EMAIL PROTECTED]>
Via, but not speaking for: Texas Instruments Ltd.
