Dan Sugalski wrote:
>
> Besides the size and clunkiness issues, there's another problem. String
> evals in a perl 5 section of code will expect to be parsed as perl 5, which
> kinda precludes the whole "compile perl 5 to bytecode and pass it through
> the p526 converter" solution. Makes mixing and matching perl5 and perl 6
> code rather more difficult. :(
So, there seems to be an impass: Backwards compatibility is good, but
Perl 6 by design is going to be fundamentally incompatible.
Why couldn't we only install Perl 6 as /usr/bin/perl6? (Someone else
suggested this as well, I believe.) That way, "perl" would be 5, and
"perl6" would be 6. If you want a Perl 6 script you *have* to say
#!/usr/bin/perl6
At first glance, that seems ugly. But there are a couple benefits:
- Completely sidesteps the backwards compatibility problem,
since /usr/bin/perl will remain untouched.
- Makes it obvious to the user that this is not compatible,
and it's time to read the docs to figure out why format()
is "missing".
- Pre-emptively fixes the documentation; old Perl books will
tell a person to use "/usr/bin/perl", and newer Perl 6 ones
will say "/usr/bin/perl6". Then, people aren't confused by
why old code seen in books or on the internet doesn't work;
in fact, it still does.
- Fixes compatibility the *other* way too - new articles
written on Perl 6 which say "/usr/bin/perl" (but the site's
copy is Perl 5!), so the code doesn't work and people are
confused and frustrated.
- This issue is solved for Perl7/8/9/10/912098. At each major
release, the binary is named the release number. That is,
for Perl 6.0.0 thru 6.9.3, it's "perl6". For Perl 7.0.0
thru 7.4.5, it's "perl7". And so on.
Perl 6 wouldn't be the first language to do something like this; PHP4
and PHP3 are incompatible, and this is solved with different file
extensions. Here, you would just call a different interpreter.
-Nate
