Re: Ensuring forward compatibility

[dragonchild]

I think the important feature here is that Perl6 scripts will be able to use Perl5 modules and classes, among other languages. The parser will have to disambiguate when it is handling a Perl6 module, a Perl5 module, a PHP module, etc. Hence, the difference between package and module/class/whatever other scopers Perl6 will have.

As for scripts ... I think that this is a straw man. If you pass a PHP script or HTML file to Perl5, what would you think is going to happen? Perl6 is not the same language as Perl5. It is a different language that just happens to have a common subset. This is not a C to C++ upgrade. Very few Perl5 scripts will actually compile under Perl6 syntax, and this is a good thing.

Let me put it this way - what happens if you mix your Perl binaries right now, in the 5.x series? You might get lucky ... you might get spewed. Script authors will just have to be careful. (Or anal, with 'package main;' and 'module Main;'. I plan on being careful.)

[kelan]

The problem is that the same binary (eg, /usr/bin/perl) will be able to load both Perl 5 and 6, so we need some way to tell it which we're feeding it.

[Vautrin]

On a Linux, Unix, BSD, or Unix like system it is possible to install perl 6 as /usr/bin/perl6, right alongside perl5. As a matter of fact, for most of my programs, as I upgrade, I keep versions separate. i.e. I have /usr/local/apache2/ linked to /usr/local/apache2.49 while I also have /usr/local/apache2.48 installed on my system

[kelan]

Ah, but the difference between Apache 2.48 and 2.49 is unlike the difference between Perl 5 and 6. This is more like the difference between the Apache 1.3 and 2 series, because the two versions are not really compatible.

In your example, almost anything looking for Apache 2.48 would be fine if it used 2.49, so using a symlink is fine. But a program looking to be run as Perl 5 would not work if interpreted as Perl 6. Everything would be fine if we started using separate binary names, eg perl5 and perl6, but that's kind of a hassle. People would rather just be able to say #!/usr/bin/perl and have it work either way, which is the purpose of this discussion. How do we get it to work either way, reliably?

Personally I think we should give up on that idea. It seems more reasonable to me just to say that Perl 6 will be perl now (well, after it's released), and Perl 5 will be perl5. Otherwise we're condemning ourselves to always run in Perl 5 mode by default, forever more. But, on the other hand, it causes problems for those who have a big library and don't want to have to go through and change all the shebang lines to /usr/bin/perl5, but still have a Perl 6 installed without having to write /usr/bin/perl6.

It's a tough problem, but it seems like since Perl 6 is already committed to not worrying about backward compatibility, why force a default mode that we're hoping will go away eventually anyway? If we don't do it now, at what point in the future will we be able to say, "Okay, let's make Perl 6 the default, finally." I would argue that we'll never be able to do it unless it's upfront.

Alright, enough rambling. Back to your regularly scheduled forum.

[kal]

I'm not so sure about your straw man. Yes, we know that Perl 6 is very different to Perl 5. But, to many people (dare I suggest most), it's likely that Perl is Perl is Perl. They will understand things like "not a new enough version", but not the arcane messages (like I posted above).

Look at it the other way around: if there is a way to make Perl 6 scripts fail under Perl 5 with an error saying "This is Perl 6 code, but you're running Perl 5", surely that is the best way to have it? After all, if you mix your Perl binaries in 5.x, judicious use of 'require' means that you're not going to get "spewed" as often as you could do, and when it happens you know why.