develooper Front page | perl.perl5.porters | Postings from March 2021

My thoughts on the recent proposal on The Future of Perl

Thread Next
From:
Andrew Hewus Fresh
Date:
March 26, 2021 01:08
Subject:
My thoughts on the recent proposal on The Future of Perl
Message ID:
20210326010814.GU48741@us.holligan.net
I thought perhaps you might like to hear my somewhat unique perspective,
although definitely not saying anything others haven't already said.  My
perspective comes from my three hats, as a perl hobbyist and CPAN
author, the maintainer of /usr/bin/perl in OpenBSD, and as someone who
has written perl professionally for just short of ten years (the fifteen
before that I wrote more and more perl as a sysadmin).

You will notice that none of those hats are PSC member or perl core
committer, so keep that in mind.

Overall, I think the plan is excellent and hope it mostly moves forward.
There's only one tiny issue that might keep me from coming along for the
ride.

tl;dr: if the default, without conscious indication of something else,
for bin/perl is anything but a "best effort at perl5" I believe I, and
many other people will be stuck on perl5 forever and never be able to
use v7, or v8, or anything later.



First, I should probably explain what I mean by a "best effort perl5".
It is the thing we have gotten from perl on code without "use v5;"
specified, likely since perl 5 was first released.  Most things work,
strict and warnings pragmas are disabled, and sometimes things get
deprecated and removed.   For example, `for my $x qw( a b c ) {}` works
find up to v5.12, but warns in v5.14/v5.16, and in perl 5.18 and later
is fatal.  So, specific syntax gets removed with appropriate
bikeshedding over how much of the CPAN and "darkpan" it will break.  I'm
sure folks can come up with their own examples, for example rjbs
mentioned support for arybase.  I can deal with this slow change to fix
problematic code, however enabling "use strict" or "no
bareword::filehandles" by default?  Those are a step too far without a
"use vX" declaration.

The slow reduction of "best effort perl5" to supporting less and less of
the long tail of all possible perl5 code is something I would be able to
deal with, but I don't think I'll be able to upgrade to a version of
perl with a hard line that refuses to run code where the only obstacle
is inserting "use v5" or "no strict" into it.  Based on listening to
some folks who work in the core talk, I believe that the amount of
things that will be removed from this "best effort perl5" will actually
end up in fewer changes than what we've had since perl v5.10, since it
will really only be things that are too hard to do in core without
removing or changing that feature.


When wearing my hobbyist hat, this change wouldn't be much of an issue,
I could mostly fix code that I write and whatnot and if there is some
magic solution adding that to any CPAN modules I may install, I'm mostly
OK.

Unfortunately, I have been fairly well convinced that there are swaths
of the CPAN that will remain useful for a long time without having a
correct way of adding that "use v5" to them.


Putting on my OpenBSD hat however, there are likely places where this is
not OK, and why I would be stuck with perl 5.34.x forever.   The
specific example that comes to mind is that I know some folks do
interoperability testing between different versions of LibreSSL and
OpenSSL.  There are bits of perl that exist in those old releases that
can't have the line added easily, especially by folks who may not know
perl and would only know that "perl broke it" but have no solution for
fixing it unless google comes up with something for them to paste in.

The example code I mean, which has been with OpenSSL for a long time,
would not compile under use strict or no bareword::filehandles and
possibly not under some of the other proposed default pragmas.

* https://github.com/openbsd/src/blob/master/lib/libcrypto/x86_64cpuid.pl
* https://github.com/openssl/openssl/blob/master/crypto/x86_64cpuid.pl

There are likely thousands of scripts written by the previous sysadmin
who knew just enough perl to make it work that are in a similar
condition, and the people left to fix it would just know that "perl
broke their stuff", in my opinion, for no good reason.


Wearing my work hat, I can't say anything official, but again, unless
the CPAN issue is magically solved, I don't know how we'd ever be able
to move to perl v8, and with the bugfix support cycle for perl v5
appearing like it would outlast the support cycle for perl v7 we would
be hard pressed to invest the time to upgrade, and I'd really like to be
able to.



Although many folks have already said it better, this is the way I would
like to see it work, although I have not considered nearly as many
possibilities as other people and so may convince me to change my mind
on some details.

The most important is that without some other indicator, it would be as
if there was an implicit "use v5" in the scope.

I think there could be multiple ways to provide that indicator, but I
agree with many other folks that adding "use vX" to the top of the file
is not "too much" or too large a hurdle to get the semantics you expect
your code to run under.  I don't mind if someone decides to use
"PERL_DEFAULT_REVISION=8" or perl notices the #! has "perl8" in it, or
that $^X ends in qr/perl8[^/]*$/ in those cases maybe choose a different
default when no other exists.  Other people have different preferences
on what these indicators should be and I can see arguments for several
options.


As Exodist said so well, I would not mind at all if there was a
non-fatal warning of some sort if the "top level" code didn't include a
"use vX" line in order to help new perl programmers learn some best
practices.  To that end, as suggested by someone else, "use strict"
should appease this warning as if "use v5" had been specified as well.
A compile time and environment variable to disable it would bonuses.  I
think this one item would address the issues with people copying and
pasting code they don't understand, and I think it would do a better job
of it than defaulting to "current revision semantics".



One last item that I think is important is what I think "use v7.1.2"
should mean.  Well, I think it should require perl semantics >= v7.1.2
and < v8.  That means, for example, "use feature 'signatures'" could
change meaning under "use v7" vs "use v8" and not break things, suddenly
there are versioned features "for free".   These "lower" versions would
have to be provided on a "best effort" basis as I described above for a
"best effort perl5".

I don't think there's anything in that example LibreSSL script linked
above that would ever have support removed from the perl core codebase,
so I don't understand why refusing to run that script to be able to
avoid saying "use v8" is worthwhile trade.  Especially when adding it
has other benefits such as being able to change semantics under "use
v10" or "use v42" and not break things that say "use v7" and make static
analysers lives easier.

l8rZ,
-- 
andrew - http://afresh1.com

At the source of every error which is blamed on the computer, you
will find at least two human errors, including the error of blaming
it on the computer.

Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About