Jumping the gun a little....
With the pluggable parser architecture, would it be a Good/Bad/Ugly Thing to
freeze the parser itself after each Perl release?
One of the omnipresent arguments against any change is how it affects legacy.
Although Perl 6[.0] is a recognizable departure from Perl 5.x syntax, so have
been Perl 5.x from Perl 5.(x-1) and will be Perl 6.x from Perl 6.(x-1), if
only to a lesser extent.
Perl 6 is planning on addressing the bulk of the Perl 5 legacy issue with a
pluggable parser capable of parsing Perl 5.n. Why not do the same thing in
the future with minor revs?
Currently, with each release, the parser is extended/fixed/modified in place
with the development of the next version. Instead, why not freeze the parser
in place at each release, and then use it as a jumping off point for the next
parser? The frozen parser could then be CPANned as a legacy parser.
Bennies:
- Guaranteed language basis for the future. Code written explicitly for Perl
6.0 will be parsed according to Perl 6.0 rules.(1) Code written generically
for perl can easily be "rolled back" if the next version of Perl breaks some
reliance on the older parsing rules.
- Fits within the "mix and match" module munging that is being planned. Perl
6.0 code could potentially interface with Perl 7.0 modules/packages/classes,
and vice versa.
- By definition, doesn't need to be maintained.(2) Once it's frozen, it's
frozen. This is behavior that people expect, however intentional or not the
behavior actually is. Er, was.
Troublespots:
- (1) Parsing would be consistant, but obviously runtime behavior could still
change, depending, for instance, on whether the parse-tree optimizer would be
coupled with the parser or with the underlying architecture. Future
optimizers may subtly change the behavior of a legacy parse-tree. This is
the same issue that will plague "compiled" code, so it needs to be addressed
somehow anyway.
- (2) Obviously, opcode deletion (or something similar) may require the
parser's output to be changed.
- Who wants umpteen different perl parsers lying around their code base?
Other impacts:
- C<use> semantics would have to be changed. Or whatever the parser
identifier will be. You'll need to differentiate between an exact match and
a minimum match.
use perl 6.0;
use >= perl 6.0; # or use perl >= 6.0?
--
Bryan C. Warnock
[EMAIL PROTECTED]
