Front page | perl.perl6.language |
Postings from April 2001
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. LarryThread Previous | Thread Next