Front page | perl.perl5.porters |
Postings from June 2020
Re: Announcing Perl 7
Thread Previous
|
Thread Next
From:
Joseph Brenner
Date:
June 26, 2020 18:07
Subject:
Re: Announcing Perl 7
Message ID:
CAFfgvXVh3h2_SLs+=QuOgA08NU+YBtEZfTJK043UgwNRUAt-dA@mail.gmail.com
I think announcing "Perl 7" could indeed be useful as a headline
grab, but if there's no compelling tag line to go with it, it's not
going to ultimately lead to much. The best brian d foy could do
was: "Perl 7.0 is going to be v5.32 but with different, saner, more
modern defaults." I submit that "sucks less, more modern (but
still scared of unicode)" isn't really going to do it.
When I tell people what perl5 is good for, I say things like: "it
has a fast, full-featured regex engine with full unicode support".
It is indeed awkward that getting unicode support turned on requires
inside knowledge-- "use utf8" doesn't do it, "use utf8::all" does,
but it isn't even a core module.
I hear what Sawyer X is saying about how a unicode default would
break lots of things, but that's indeed the argument against
breaking backwards compatibility. Someone who objects to this
doesn't deserve to be classified as the equivalent of an annoying
conference attendee that harasses people.
This scheme is sounding to me like a fork-in-denial: is the idea
that /usr/bin/perl is going to stay Perl 5 so the linux distros can
avoid breakage? If that's the way it plays out, then we're
replacing one kind of insider knowledge with another: you need to
understand that that perl binary that shipped with your system isn't
the real perl any more.
On 6/26/20, Karen Etheridge <perl@froods.org> wrote:
> On Fri, Jun 26, 2020 at 9:04 AM Dave Mitchell <davem@iabyn.com> wrote:
>
>> My understanding was that, by default, perl7 will enable many of the
>> optional features available via 'use feature X' and/or 'use v5.32.0',
>> plus possibly some other stuff.
>>
>> I think that this will break a *lot* of existing code and CPAN modules.
>> Which is at the heart of my objection.
>>
>
> I am greatly concerned about this as well.
>
> One thing that could help (and I have asked for this in the past;
> unfortunately I have lacked the tuits to do it myself) is to compile
> variants of perl with these pragmas forcibly turned on, and smoke all of
> cpan with it to see the outcome. As a cpan author and janitor, I would
> certainly appreciate being able to see which distributions within my
> control are affected by certain pragma or feature options, so that I can
> proactively move to make appropriate fixes. There may also be some
> surprising findings from this exercise that would help inform us which
> pragmas and features should be enabled or not enabled. Core and dual-life
> modules would also no doubt be affected, and they MUST all be fixed for
> whatever default feature set is decided upon.
>
> This doesn't tell us anything about the darkpan, of course, but it would at
> least give the growing list of keen-to-see-p7-happen volunteers something
> to set their attention on in the short term. (I see the Pull Request Club
> is enjoying a revival thanks to the TPC too!)
>
> --
> To unsubscribe from this group and stop receiving emails from it, send an
> email to doom+unsubscribe@kzsu.stanford.edu.
>
Thread Previous
|
Thread Next