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

Re: Announcing Perl 7

Thread Previous | Thread Next
From:
Joseph Brenner
Date:
July 3, 2020 18:15
Subject:
Re: Announcing Perl 7
Message ID:
CAFfgvXUwiQZDdhz1KniauBVdXXJn4QdgQ6Mj_OLxiv1mJPLUBg@mail.gmail.com
Briefly: I'm still on the side of "use v7": I don't see how zero
boiler-plate is achievable.

I'm trying not to repeat other stuff people have said, but
there's a couple of things I haven't heard yet, so...

Sawyer X remarked:

> I would venture that while you can still use "use v", you probably
> don't want it anyway, even in 5.32.0. I know I couldn't use it in
> any code I have, whether professionally or on CPAN.

All of my Perl6/Raku scripts begin with "use v6": if I make a
mistake and run it with a "perl" binary instead of "perl6" it
complains, and I find out immediately.

It is true that my CPAN code, at the moment, just gets a "use 5.10.0".

> People do not actually use "use v". This is what we've seen with
> it so far. CPAN is an example, and every code-base I touched and
> discussed with peers had rarely used it.

CPAN authors typically are trying to support as wide an audience as
possible, and hence are reluctant to exploit new features.

As you know, there are indeed shops that are tremendously
conservative at upgrading their stack.  (I was working at one place
where ops was proud of themselves because they were finally rolling
out 5.10-- and that was around the time 5.20 was coming out...).

Myself, I don't see any reason that "v7" has to work exactly the
same way "v5" does (certainly "v6" doesn't).


I see arguments like "But Python managed to do it's 2 to 3
transition successfully".  Do you honestly expect that Perl will be
treated the same way as Python?  Because the software developer
community is known for it's fair, rational judgment?

Myself, I expect that if the Perl 7 project stumbles anywhere
you can expect a chorus of "Look, it's Perl 6 all over again."


On 6/26/20, Sawyer X <xsawyerx@gmail.com> wrote:
> On Thu, Jun 25, 2020 at 11:16 AM Dave Mitchell <davem@iabyn.com> wrote:
>>
>> On Wed, Jun 24, 2020 at 11:49:30PM +0300, Sawyer X wrote:
>> > * Major versions will be used for two purposes: 1. Turn on features
>> > and pragmas by default, 2. Remove syntax from the language.
>>
>> I want to be on the record that I extremely strongly oppose this change.
>
> Noted.
>
> I'm sorry you feel this way, but I hope to turn this around, or at
> least to change that your vehement disagreement will be accompanied by
> understanding why this decision was made.
>
> I have given very brief responses below, but at the bottom, I go at
> more length on what I think is the main topic you object to. It
> doesn't cover everything in email, but it's not easy for me to address
> everything you wrote in one go, so please bear with me.
>
>> I think if people want to use the new modern perl, they just put this
>> one simple line at the top of their code:
>>
>>     use v7;
>
> This cannot achieve what we want. I don't believe it even achieves
> what you suggest. As explained below, "use v" is not practically
> useful.
>
>
>> this makes everything forward and backwards compatible, and eases the
>> transition. The thing is that old perl binaries back to at least 5.8.x
>> recognise this syntax and will produce a helpful error message:
>>
>>     $ perl589 -e'use v7'
>>     Perl v7.0.0 required--this is only v5.8.9, stopped at -e line 1.
>
> We are not removing "use v" but we are recognizing that it doesn't
> provide what we need. I would venture that while you can still use
> "use v", you probably don't want it anyway, even in 5.32.0. I know I
> couldn't use it in any code I have, whether professionally or on CPAN.
>
>
>> this helps everyone: writers of perl7 code will know what the problem
>> is when they accidentally run their code on an old perl binary, rather
>> than getting some obscure error message.
>>
>> Older code continues to run without modification - you don't
>> have edit every source file to add a 'use compat::perl5' line.
>> You don't have to update every existing perl installation to add the
>> compat::perl5 module just so that existing code will continue to run.
>> CPAN continues to work.
>
> If you have numerous files, they each have to have "use v".
>
> Your proposal doesn't change the fact that a use statement needs to be
> added by someone. You suggest that this particular someone not be
> those keep their code static, but those who want to actively write
> code. That's a fair position, but it's only another coin of the plan's
> argument. You say "New users add 'use v'" and I say "Old users update
> or add 'use compat::perl5'". The same idea of adding lines of code,
> just the question is who.
>
>
>> 'use v7' also allows the new stuff to be scoped to a single source file;
>> other .pm files can still be included unmodified using the old perl
>> syntax.
>
> That's actually far worse and is a major reason "use v" is not suitable.
>
>
>> Look, we've got this great built-in mechanism, 'use vx.y.z' that's been
>> around forever. It hasn't seen much use yet, because frankly there's
>> been very little call for it, since there hasn't been much new
>> non-backcompat stuff so far. But its been sitting there waiting for use
>> to
>> use it.
>
> This mechanism isn't in use because it does not work.
>
>
>> In 5 years or whatever, it will also save our bacon when perl8 is
>> released; suddenly all that source code with 'use v7;' at the top will
>> continue to work on the perl8 interpreter running in perl7 mode. Rather
>> than suddenly all breaking.
>
> This isn't the scenario. It's the scenario you are painting in the
> email. Why would all code suddenly break when we release version 8?
>
>
>> It helps IDEs as well - now they can look at a source file and know
>> instantly what major release of perl this file was written against, and
>> so how to syntax highlight etc.
>
> Are you suggesting that IDEs create different parsers for the Perl
> syntax based on pragmas turned on in scopes? Can you give an example
> of an IDE that does this now?
>
>
>> [...]
>
> I'm cutting the rest because it is both too long and includes several
> points raised which makes it difficult to respond to each section
> separately at length in one email.
>
> Instead, I will focus on one particular aspect: "use v" does not work for
> us.
>
> 1. People do not actually use "use v". This is what we've seen with it
> so far. CPAN is an example, and every code-base I touched and
> discussed with peers had rarely used it. It is true that this is
> anecdotal because I haven't touched or discussed every code-base, but
> I am in touch with a few major Perl shops. It is rarely used by any of
> them. This has to account for a fair portion of active Perl code and
> this anecdote does means something. We have a mechanism we believe is
> superior and gives our users what we think we want. Our users don't
> use it. Aergo, our mechanism isn't the gift to developers we thought
> it is.
>
> 2. "use v" turns on *everything* till this version. With 7.0, we do
> not intend to turn on everything. If you were to take a large
> code-base, you will not be able to easily transition it to
> *everything* in feature.pm. It's impossible, even with an exhaustive
> set of tests, because the number of changes, both to syntax and
> semantics, will require a lot of updating and probably tests you
> haven't even thought of. A good example is unicode_strings. If I had
> written 10K lines assuming my strings are bytes, I'm screwed. Will I
> get the time to actually go ahead and change all of my code to assume
> otherwise? Probably not. For 7.0, we will turn on very few pragmas and
> features, to allow people to make a relatively seamless update. This
> is already being tested with a few stakeholders and is proving fairly
> doable.
>
> 3. "use v" being lexically scoped is even worse in this respect.
> Different code within the same code-base that touches the same data (a
> fairly common occurrence) will now have some lines of code that assume
> the string is bytes and some assume it is Unicode characters. This
> makes the code nearly impossible to work with. If in #2, I expressed I
> can't move a large code-base to every possible feature and pragma at
> once, the fact that it's lexical can only make it worse for me because
> I don't know if a line of code that has it enabled will trigger a line
> of code in a different package which doesn't have it enabled.
>
> 4. "use v" is meant to make "use feature" easier. Using feature.pm
> indefinitely makes it impossible to ever remove code, which is also
> something we are actively trying to change. This means that "use v"
> does even more to cement feature guards' infinite existence. Why
> remove crufty features in the code when we can just keep it on by
> default and force all developers to indicate they don't want it?
>
> An example of this situation is as follows:
>
>   package Foo {
>     use feature qw< unicode_strings >;
>     sub match { print $_[0] =~ /ss/i ? "Foo: match\n" : "Foo: no match\n" }
>     sub match_with_bar { Bar::match(@_) }
>   }
>
>   package Bar {
>     sub match { print $_[0] =~ /ss/i ? "Bar: match\n" : "Bar: no match\n" }
>   }
>
>
>   my $x = "\xDF";
>   Foo::match($x); # works
>   Foo::match_with_bar($x); # doesn't work
>
> To summarize:
>
> * With "use v" I need to add this *everywhere*.
> * With "use v" I need to deal with even significantly breaking changes
> and I need to deal with all of them at once. (Like within a
> single-but-large file.)
> * With "use v" I need to add this to all files and deal with all of it
> at once because due to it being in a package scope, it can create a
> vast action-at-a-distance behavior. I could trigger code within my
> code-base which wasn't updated or code in a module which wasn't
> updated.
> * With "use v" the code will not get removed, which is the opposite of
> what we want
>
> "use v" is effectively a non-starter. It doesn't allow people to
> progressively update their code, only gives them an all-or-nothing
> "solution." That's not a real solution. As much as it doesn't help
> them, it doesn't allow us to remove any code, ever.
>
> --
> To unsubscribe from this group and stop receiving emails from it, send an
> email to doom+unsubscribe@kzsu.stanford.edu.
>
>

Thread Previous | 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