Beefy Boxes and Bandwidth Generously Provided by pair Networks
Come for the quick hacks, stay for the epiphanies.
 
PerlMonks  

Re: Re: Re: Ensuring forward compatibility

by Vautrin (Hermit)
on Apr 14, 2004 at 14:18 UTC ( [id://345064]=note: print w/replies, xml ) Need Help??


in reply to Re: Re: Ensuring forward compatibility
in thread Ensuring forward compatibility

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


Want to support the EFF and FSF by buying cool stuff? Click here.

Replies are listed 'Best First'.
Re: Re: Re: Re: Ensuring forward compatibility
by kelan (Deacon) on Apr 15, 2004 at 16:55 UTC

    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.

      Changing shebangs should be no problem for an abbot.
      #! /usr/bin/perl use strict; use warnings; use File::Find; File::Find->find(&main::wanted, '/'); sub wanted { if (-T $File::Find::name) { open ("FILE", "< $File::Find::name") or die ("$!: Could not open " . $File::Find::name); my $first_line = <FILE>"; unless ($first_line =~ m(^\#\!\s{0,1}/usr/bin/perl\n$) { return 0; } $first_line =~ s[perl][perl5]i; while (<FILE>) { $first_line .= $_; } close ("FILE") or die ("Could not close file " . $File::Find::name . " because $!"); # create a temp file so if we get interrupted # we won't lose our data `cp $File::Find::name $File::Find::name~`; open ("FILE", "> $File::Find::name") or die("Can't open $File::Find::name for " . "writing because $!"); print FILE $first_line; close ("FILE") or die ("Cannot close $File::Find::name " . "because $!"); # get rid of the temp file unlink ("$File::Find::name~"); } }

      Want to support the EFF and FSF by buying cool stuff? Click here.

        I would personally have no problem doing something like this (or even recommending it to a supervisor if Perl 6 were being considered), but I can picture a lot of people grumbling if Larry were to mandate it as The Way Forward.

        Again, I support a move like this that would separate the binary names. It would make the whole "How do we decide if it's Perl 5 or 6?" question moot. It's the masses that I imagine are (or would be) opposed to the idea that are keeping us in this mess.

      it seems like since Perl 6 is already committed to not worrying about backward compatibility

      Perl 6 is promised to be compatible in 80-90% of the code out there. Sometimes it may have a radically different implementation (such as the => operator), but will end up working the same way in practice. Other things have had significant additions, but will still work the old way if you really want to (like subroutine signatures--but realize you'll be missing out on a lot of really cool stuff if you ignore them). Regexen are the only major subsystem I can think of that are complete incompatible.

      ----
      : () { :|:& };:

      Note: All code is untested, unless otherwise stated

        I think all that's been promised is that "Perl should stay Perl", as A1 put it. This obviously means that most of the things that make up Perl will stay because otherwise it would no longer be Perl. However, what I meant is that the designers are not trying hard to keep things for the sake of backward compatibility only.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://345064]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others lurking in the Monastery: (5)
As of 2024-03-29 12:05 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found