All that follows is merely MHO, so feel free to disregard.
On Fri, 11 May 2001, Nathan Wiger wrote:
> Well, I think we should take a step back and answer a few key questions:
>
> 1. Do we want to be able to use Perl 5 modules in a
> Perl 6 program (without conversion)?
I would say it's absolutely mandatory that we be able to use perl
5 modules--half the power of Perl is CPAN.
>
> 2. Do we want to be able to switch between Perl 5 and
> Perl 6 in a single file (by using "module" to dictate
> P6 and "package" P5)?
This seems like something that could be left out without
outraging too many people.
> 3. Do we want to assume Perl 5 or Perl 6 code? If we
> assume P5, then we have to look for "module" somewhere.
> If we assume P6, we can look for a number of differences,
> such as $foo[1], $foo{bar}, etc to identify P5 code.
It will probably be easier if we assume P6 code, but P5 policies
(warnings, strictness, etc).
> 4. Do we want to be able claim 100% compatibility, or
> "99% except typeglobs", in which case if *foo is
> seen we just drop with "Typeglobs not supported"?
I don't see that we *can* claim 100% compatibility...there's
simply no way, in the real universe, that every P5 script ever written
will run flawlessly through the P6 interpreter (unless we simply swap to
the P5 interpreter upon recognizing P5 code, but even that might not work
in a mixed environment).
On a related topic, here's a crazy off-the-cuff thought...haven't
spent many cycles on it, not sure if it's worth anything, but I'll throw
it out to be shot at:
Can we break the p526 functionality out into a normal P6 module
and, for the first few versions of P6, have the interpreter automatically
load this modules and pass all other code through it before actually
starting to interpret it? This would keep core size down, make the
translator easily available as a separate system/API, and make it easy to
turn off the translation after enough time has passed that P6 is the
assumed standard.
Dave
