Front page | perl.perl5.porters |
Postings from June 2020
Re: Announcing Perl 7
Thread Previous
|
Thread Next
From:
Tom Molesworth via perl5-porters
Date:
June 30, 2020 05:23
Subject:
Re: Announcing Perl 7
Message ID:
CAGXhHdkDY7tuyzJmJ0q_iDQY+BNJh3JDJ-f_g_bVWGB6MOcnbQ@mail.gmail.com
On Tue, 30 Jun 2020 at 12:40, Darren Duncan <darren@darrenduncan.net> wrote:
> 2. I also completely agree that IF Perl code lacks an explicit version
> marker,
> then a v7+ Perl interpreter should indeed interpret it as the latest
> version of
> Perl it understands implicitly, rather than interpreting it as Perl 5.0.0.
>
Just to put a few numbers to this...
There are at least 757 distributions on CPAN that would break due to
signatures being enabled:
https://grep.metacpan.org/search?size=20&q=%5Esub+%5Cw%2B%5C%28%26&qd=&qft=
Some of them - AnyEvent, for example - are likely to encounter, ah...
"political issues" (see the fallout from sort-in-place hidden feature for
reference).
There are at least 150 distributions which would break, or at least have
misleading documentation, if `no indirect` becomes default:
https://grep.metacpan.org/search?q=%3D+new+%5BA-Z%5D&qd=&qft=
That's a low estimate, the search timed out and there are likely many other
variants of indirect syntax.
So one concern that does not seem to have been addressed by the "enable by
default" proposal is "what about CPAN". It used to be a selling point for
Perl, would be a shame to lose that.
Changing the language by default, rather than a one-line opt-in, would thus
seem to cause problems for at least two groups of people:
- anyone who has existing Perl code
- new developers who hear about CPAN and would like to use it in their new
code
That second group may lose some enthusiasm if they keep running into
modules that don't even install. This of course ignores the possibility
that some modules can be installed but then exhibit subtle differences in
behaviour due to new defaults.
Don't take anyone's word for this, though - give it a try yourself!
Here's a script that should work as a starting point to identify "does this
CPAN module break":
perl -e'BEGIN { @INC = (sub { my ($path) = grep { "$_"; -e $_ && !-d _ &&
!-b _ } map { "$_/$_[1]" } grep { !ref } @INC; open my $fh, "<", $path or
die $!; return \"use strict qw(vars subs); no indirect; use utf8; use
feature qw(signatures); use warnings; ", $fh }, @INC); } eval "require $_"
or die $@ for @ARGV' List::UtilsBy
Note that we can't start with `use strict`, because many of the core
modules would fail with that in force. I suspect it's also not a complete
list of the proposed v7 directives. The main failure with this example
(List::UtilsBy) is related to signatures - but I would suggest that testing
it out on the dependencies that you're using in real code, seems that would
give useful data points for the discussion?
I can't immediately see how this amount of breakage could be resolved
without some discomforting workarounds ("old defaults for installed modules
or internal @INC paths, new defaults for app code and PERL5LIB additions")
or putting `use v7;` or equivalent in new code. Of course, this is just a
failure of imagination on my part - the Pumpking doubtless has some magic
up his sleeve that will put these concerns to rest!
Thread Previous
|
Thread Next