Front page | perl.perl5.porters |
Postings from July 2020
Re: Perl 7 - updates
Thread Previous
|
Thread Next
From:
David Green
Date:
July 5, 2020 16:20
Subject:
Re: Perl 7 - updates
Message ID:
20200705162046.28328.qmail@lists-nntp.develooper.com
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
perl.org/obsolete.”)
>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