> 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)?
For a while, quite possibly, I'd say.
When 5.6 came out, I was in module hell, trying to get 5.005 modules to
compile with 5.6. Most of the ones giving the most trouble were the most
popular/demanded. That's not something I'd like to see repeated.
The largest problem may be in non-compiled modules, perl-only,
user-designed. If I have a store of these, it might be handy to keep them
around for a while. I'm not going to gripe about this as much as others may,
becuase my modules are small and tidy. Xerox will likely have a different
opinion.
> 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 personally don't see how this is helpful outside the context of using Perl
5 modules. Actually, outside of using Perl 5 modules (interfacing with them
or "use"ing them), I don't see how this is anything but obfuscated choo-choo
train Perl.
Answer: not as stated, no.
> 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.
We may not have to assume either, as long as we can deal with separate
executables or separate symlinks during a transition.
Answer: no. (Even though it wasn't a yes or no question... you cheated ;-)
> 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 think we should claim compatibility at all. If we have the ability
to work with either/or, then they can be separate entities IMO. The hardest
part is convincing Dan that we need the ability to work with Perl 5 or Perl
6 with AND without markups in either.
Answer: no.
> The more we answer "yes" then the more complex it is. ;-)
David T. Grove
Blue Square Group
[EMAIL PROTECTED]
[EMAIL PROTECTED]
