Re: Ensuring forward compatibility

Wouldn't it be a good solution if the perl6 had a different name?

I mean, suppose that when you install perl6, it owuld install its binary as /usr/local/bin/perl6, and a link to it as /usr/local/bin/perl. Then, it could decide on what kind of code something is from the name it is started, and the shebang line (which would have higher privilege then the actual executable name). As most scripts already have a shebang line (even if not used by the os, just the switches are read by perl), this would work with great reliability. There might still be a mechanism to override this, such as package in one way, and for example module or I don't know what in the other way.

(Maybe Larry is affraid to do this as this would admit that perl6 and perl are a different language.)

Update 2010-04-15: python3 does this now.

Comment on Re: Ensuring forward compatibility Select or Download Code

Replies are listed 'Best First'.
Re: Re: Ensuring forward compatibility by flyingmoose (Priest) on Apr 14, 2004 at 14:02 UTC
I suggest we use newbie convention and call it Perl (watch the case!), so we could say "you need to use Perl not perl to parse Perl 6 Perl, because you use perl to parse Perl 5 Perl, PERL is reserved for Perl 7". That would be funny, especially for Windows users. Nah, seriously, I like your idea best. This is what python does between 2.2 and 2.3 and it seems to work for them. Unambigious, and dead-on straight forward. Plus, it means the interpreter/VM can be a little cleaner for not understanding compatibility. This doesn't mean the perl6 executable couldn't detect the lack of a module/class and option out to perl5 via exec...	[reply]
Re: Re: Ensuring forward compatibility by hardburn (Abbot) on Apr 14, 2004 at 14:03 UTC
This is similar to why you see some Perl code around that has a shebang line of `/usr/local/bin/perl5`. During the transition from Perl4 -> Perl5, there needed to be seperate intepreters. Of course, by now everyone who is going to convert their code to Perl5 has probably already done so, but we're still stuck with some silly shebang lines. IMHO, it's better not to force the seperation if it's not needed, espcially if the underlieing runtime (Parrot) will handle both. ---- `: () { :\|:& };:` Note: All code is untested, unless otherwise stated	[reply] [d/l] [select]