-- On Wed, 4 Sep 2002 07:45:37 Sean O'Rourke obviated: To me a language's grammar, once >defined, shouldn't do a lot of changing, internally or otherwise. When >was the last time C's grammar changed? Or even gcc's implementation of >it?
Granted . . .mostly. Were talking about Perl, the language designed to evolve. How much did the Perl grammer (even if there was no definitive one in the Perl 6 lex-on-the-fly sense) change between Perl 1 and Perl 5? Perl 5 and Perl 5.8? I think the answer to the first question (which I suspect is "a lot") point to perhaps a different issue - how much do we expect Perl to change after this rewrite, and how are we accomodating Perl's inevitable evolution? The answer to the second question (which I think is probably "a little, but some") is more to the point here. Parsing small or experimental features (vstrings and subroutine attricute come to mind) will probably cause changes to the parser. I'd like to keep the potential to introduce such features without breaking existing code. All that said, perhaps there is a solution. I'm not much of a Python programmer, but as I understand it Python offers an internal module called 'future' which holds features planned for inclusion in the next stable release. The idea here is that old code gets a chance to refactor in anticipation of language changes while still bringing new features into the language. Code which uses those features simply imports from the future modules. Hugo is working on the perl6ish pragma which already brings the concept to Perl. Perhaps a Perl 6 pragma can control these feature inclusions to help protect code which accesses the parser? -Erik Is your boss reading your email? ....Probably Keep your messages private by using Lycos Mail. Sign up today at http://mail.lycos.com
