develooper Front page | perl.perl5.porters | Postings from July 2020

Re: Perl 7 - updates

Thread Previous | Thread Next
David Green
July 5, 2020 16:20
Re: Perl 7 - updates
Message ID:
On 2020-07-03 5:25 pm, Sawyer X wrote:
 >* Change "use VERSION" to mean "protocol," so "use v8" on Perl 7 will 
work. (It's effectively "give me version 8" or "I'm writing for protocol 
version 8".)
 >* Make this mechanism required by the user in future binaries.

I agree with all the reasons people gave that this is the right way to 
go. (I was assuming some like this from the announcement, apparently 
because I was thinking of the version being a “protocol” all along.)
I don’t see it as an obstacle for beginners; just part of how things 
work, like adding “#!perl”, or using “print $x” instead of just “$x” 
(after all, Perl *could* automatically print variables in void context — 
but using “print” is just the way it is). And it allows for more helpful 
messages when a novice tries to run some old P5 code from Matt’s Script 
Archive. (“You’re trying to run perl 5 code but you have Perl 10, see”)

 >On Perl 7 binaries:
 >We do not own /usr/bin/perl but we do produce binaries and provide 
suggestions for distributions (which they are free to ignore, of course).

Distributions won’t want to give up the default perl 5 because they have 
tools that work and don’t need fixing (if it ain’t broke…); but we want 
the default perl not to be stuck on v5 forever. So let’s make 
/usr/bin/perl be versions 5 *and* 7 (or any other versions). Build an 
executable that glues different versions together, so that which one you 
get depends on the name used to invoke it, or on an environmental 
variable.  Apple actually used to use such a Frankenstein-binary to 
provide two different versions of perl in a single file for OS X.

To be even more useful, it shouldn’t rely on an external cue (name or 
env variable or command-line option): if the executable is invoked as 
perl5, but it encounters a “use v7” statement, it should re-execute 
itself as perl 7 (or vice versa). This way novices, and anyone else, get 
the perl they ask for, without having to know which “perl” might be the 
right one or anything about Perl’s varied history, and existing stuff 
won’t suddenly break.

If different filenames are needed, I’d suggest adding a date rather than 
a version, e.g. ‘perl.2020-12-25’. That provides a certain psychological 
encouragement to keep up to date with the latest release, without 
suggesting that any particular release is locked into a specific version 
[‘protocol’]. So perl.2020 might handle v5 and v7; perl.2021 might 
handle 5, 7, and 8, and so on.

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About