perl parser compiles perl language into perl op-code tree.
Larry ("the" Larry) has said that a new parser might parse
other languages into perl op-code trees too.
If the parts of the language are well organized, a LanguageSwitch
(the computer equivalent of a "context switch" in a conversation,
but "context switch" is already taken in computerese, as the
basic magic that underlies multitasking) would cause as little or
as much to be replaced by the overlay as we like. Parser definition
overlays would be this third language we agree is ugly but needed to
implement this modularly.
So if we've got the vanilla language defined clearly, we can overload
stuff at a higher level. Current overloading works when you have
a function that the parser recognizes as a function, and you switch the
contents of that function, but its still a function rather than a flow
control construct.
&& and || are thought of as "functions that short-circuit" that makes
them flow control constructs. To switch them from parsing into an if-then
kind of thing into being overloadable functions, the parser needs to
recognize them as functions that will operate on both their arguments
rather than flow control to decide to evaluate or not the right side.
So if we add parser overloading, it might look like
use parseroverload qw{ && treeAnd};
use parseroverload qw{ || treeOr};
treeAnd and treeOr would have to be defined somewhere.
parseroverload language (to be determined) might be able to affect binding
of arguments to functions, are they postfix, prefix, infix, this would
give us "user definiable operators" which I think is a way of saying
that you want to put the function name between the arguments instead
of before them:
assign( $a , add($x, $y))
or
$a assign $x add $y
or
$a = $x + $y
The third version is the one that is most familar, the first is possible
in languages with implicit pass-by-reference or arguments, the second is
possible (to have it mean the same thing) if we can reprogram the
parser to treat "add" and "assign" as alternate words for what we are
used to thinking of as + and =.
Of course, when it comes time to translate the language to Chinese, having
all this stuff done in advance means we can drop in a big overlay and
call it translated.
"Bryan C. Warnock" wrote:
> Ideally, it wouldn't involve Yet Another Language, but could be done in
> one of the two Perl already has. (Or both, I suppose.) What I don't
> believe should be the goal, although it may be an unfortunate
> side-effect, is to, in essence, write the parser in Perl, and to
> require writing a full parser for every case That would, in essence,
> require dropping the user parser inline between the lexer and the real
> parser, capturing all the tokens coming out, doing the necessary
> identification and modifications, and passing the new token stream to
> the real parser. I think this was one of Nat's hook areas, and is
> similar to what Chaim suggested with how macros could work.
> This could work with very simple requirements, and could even partially
> extend to adding lexer extensions. Otherwise, why not just rewrite the
> parser in its entirety, and drop it in as a new front end?
>
> Alternately, to keep things simple, you could have a signature callback
> type mechanism, where the parser only calls your code upon certain rule
> reductions. This requires the lexer to have already sent the data to
> the parser, which could make for some icky situations, particularly
> with inspection and modification of what the parser has already done.
>
> Or, to keep things really simple, have parser pragma types that affect
> the parser internals runtime much like the rest of Perl modules affect
> Perl runtime. (This would, of course, require the parser to be able to
> support much deeper introspection than it does now. Yet Another
> Language, more complexity. But would allow for only a limited number
> of hooks, which would be a little easier to contain and a little less
> scary to deal with.) This last was basically what I was looking for
> with RFC 40. This would allow people to write their own pragmas, as
> long as they only needed what hooks were available. More radical
> changes would involve adding more hooks.
>
> I'll ponder all this today, and maybe give some examples this evening,
> perhaps showing how some of the current RFCs could be addressed.
>
> --
> Bryan C. Warnock
> ([EMAIL PROTECTED])
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
:wq
