Dan Sugalski writes:
: At 12:17 AM 4/20/2001 -0500, David L. Nicol wrote:
: >Recursive parsing is not needed. We have the HERE string, which can
: > include anything in with the rest of the code, by looking for the
: > end-token. The perl5 Inline module works that way.
Indeed, Perl 5 works that way. But not necessarily Perl 6.
: I'm not a parser guy by any means (unfortunately) but we have the distinct
: possibility of completely replacing all of the parser rules after token X
: appears, whatever that token might be.
Yes, consider that rule replacement is essentially what happens in any
parse. Whenever you run into a quoting operator, for instance, you're
switching to a different "microlanguage" that understands the following
text differently from the preceding text. It's just that, in a
standard grammar, the rules are immutable. All we're really doing for
Perl 6 is specifying that grammar rules can have just-in-time binding.
And switching complete grammars can be thought of as merely installing a
new top-level rule. If you think of grammars in OO terms, installing
new rules is a form of derivation, and switching grammars is merely
telling the parser to use a different parser object class either permanently
or temporarily. (Recall that what looks like lexical scoping to
the program at run time is really temporal scoping at compile time.
>From the standpoint of the compiler, it's as simple as push_grammar($new)
at the beginning, and pop_grammar() at the end. Or maybe even just
temp $grammar = $new.)
But I digress.
: (Heck, we may have the possibility of replacing the entire parser)
Indeed, I think it's quite likely that Perl 6's migration parser for
legacy Perl 5 will in fact be Perl 5's current C parser grafted onto a
Perl 6 syntax tree generator. That would preempt a bunch of problems
involved in trying to reconstruct exactly how the Perl 5 parser thinks,
which nobody entirely understands. With this approach we need only
remap the semantics across, and then deparse or run the Perl 6 syntax
tree as appropriate.
To be sure, we'd have to tweak the Perl 5 parser to remember extra
information such as formatting and comments. And it's possible that
someone will write a Perl 5 parser using Perl 6's parsing engine simply
for the fun of it, or for the educational value. In which case, all
bets are off as to which way we go. In any event, the long term goal
is for the Perl 5 parser to be deprecated at some point and eventually
jettisoned. For some embedded applications (places where Perl doesn't
currently fit), the Perl 5 parser may not even be available from the
start.
But I digress.
: There's no guarantee the non-perl-6 section
: will have a nice end-delimiter for us to find. Granted that won't be the
: case all the time, but it's certainly quite feasable. We might not even be
: able to rely on perl's definition of a token. (Or whitespace for that
: matter--Whitespace isn't just whitespace in python mode)
That is correct. Standard Perl 6 will end up working a lot like Perl 5,
but that's by convention, not by restriction.
Larry
