On Fri, May 11, 2001 at 10:56:38AM -0700, 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)?
This would be desirable as it would allow people to continue to use
unconverted code (particularly the wealth of CPAN code) without having
to wait. It would probably speed adoption of Perl 6. But while the
translator may be able to deal with this, I don't want to add to the
flock of seagulls already hanging around their necks.
I'd say this is "it would be nice if we can find an easy way to do it".
> 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)?
I'd say no. Although it would allow for incremental upgrades of
legacy modules, the idea of mixing two versions of Perl in a single
file makes the short hairs on the back of my neck stand up. It will
be extremely confusing.
It may also encourage small enclaves of Perl 5 rot hanging around in
Perl 6 code for many years with people afraid to touch it. It reminds
me of the continual troubles which had plauged Windows as a result of
leaving old DOS and Win 3.1 code lying around in its guts. Also MacOS
had similar problems by leaving old 68k code deep within its bowels
long after it had converted to PowerPC.
And consider the horrors of using the same variable in the two halves.
Say the Perl 6 part declares a global variable which the Perl 5 code
tries to use (or vice-versa). Or worse yet, sharing a lexical
variable. The Perl 6 part may assign all sorts of weird attributes to
the variable and make assumptions on it that the Perl 5 code is
unaware of/unable to account for. Technically speaking there's
nothing wrong with this (the translator could handle it) but the poor
programmer that has to maintain such a beast!
If the answer to #1 turns out to be "yes", then a similar effect can
be gotten by having a Perl 5 module require a Perl 6 module which uses
the same package. Then you can slowly upgrade your module by moving
more and more code off to the Perl 6 file.
> 3. Do we want to assume Perl 5 or Perl 6 code? If we
> assume P5, then we have to look for "module" somewhere.
I think Apoc 1 made it clear we're assuming Perl 5 and the method to
indicate Perl 6 (at least for modules) is the leading 'module'
keyword.
The specifics of handling scripts remains unknown, but many ideas have
been tossed about including command line flags as well as guessing
based on the name of the perl executable. (ie. symlink /usr/bin/perl
to /usr/bin/perl6. #!/usr/bin/perl6 indicates its Perl 6 code).
> If we assume P6, we can look for a number of differences,
> such as $foo[1], $foo{bar}, etc to identify P5 code.
I don't like the idea of trying to guess if its perl 5 or perl 6 at
all. A Perl 5 syntax error can suddenly make perl think its Perl 6
and report all sorts of weird errors. That will make debugging a
nightmare.
> 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 think we should table this one until more details of Perl 6 and the
flexibility of its parsing are known.
--
Michael G. Schwern <[EMAIL PROTECTED]> http://www.pobox.com/~schwern/
Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
List context isn't dangerous. Misquoting Gibson is dangerous.
-- Ziggy
