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

Re: Announcing Perl 7

Thread Next
From:
Darren Duncan
Date:
June 27, 2020 08:43
Subject:
Re: Announcing Perl 7
Message ID:
ae181430-b785-2601-4c90-1d9d27858d1c@darrenduncan.net
On 2020 June 24 Sawyer X said:
> A little while ago, I gave a talk[1] at The Perl Conference in the
> Cloud where I covered the Plan for Perl that includes the following
> significant changes:
> 
> * We will begin using major versions again, starting with version 7.

I want to start off by saying I support the general idea of Sawyer's proposal in 
principle.  I agree that its important to make some serious moves, to take 
action and fight for Perl's future.  But as with many others I feel that there 
are a number of implementing details that need to be done right, some which 
differ from the proposal as outlined.

On 2020 June 25 Tom Ryder said:
> There was even a coincidental opportunity to discuss it openly back in 
> mid-May, and at that point, your responses seemed to imply that this 
> *wasn't* already being considered, despite your assertion that this has 
> been in the works well before that time:
> 
> <http://nntp.perl.org/group/perl.perl5.porters/257448>
> 
> Could you please explain this in more detail?  Thank you.

Given that I was the person who started that very thread in mid-May, and thank 
you Tom for drawing attention to it, I do find it rather curious that only a 
month ago I explicitly raised the topic of Perl using higher major version 
numbers again, and the responses I got including from Sawyer ("this is an 
option") seemed to imply that no such action was underway or expected in the 
near term (I'm assuming the "let's not" explicit opposition was more about the 
version 34.0 idea specifically).

So Sawyer was that just you being coy about your Perl 7 plans, if what I heard 
right that they were started long before that and not just after my post?

Anyway, what follows is a short version of how I feel this Perl 7 thing should 
go down.  I am only addressing what I see as a few key points, some of which 
agree with things others have said, and some of which are possibly a new take. 
I purposely avoid talking about many of the other aspects discussed.

My central proposal is that we should be happy with a small amount of well 
thought out file boilerplate, and that a goal of having absolutely zero 
boilerplate is a worse option.

I feel that, for precedents and examples, we should not be looking to what is 
typical with programming languages, but rather to what is typical for data file 
or interchange or message formats or communication protocols or the like.

We should be conceiving a Perl program as a message and that message should have 
explicit metadata describing itself so that it can be understood in the most 
unambiguous manner possible.  This would be the boilerplate.

I propose that we retain and utilize the classic "use N;" (where N is a number) 
as the simplest form of this metadata, and make that declaration mandatory at 
the outermost scope of each file, which is to say it appears above all entity 
declarations in the file.

To be more specific, version 7.0.0 of the Perl interpreter would consider it a 
fatal error for every Perl file to not contain SOME version declaration.  That 
declaration can be any "use 5" that currently works OR any "use 7".  So the way 
that a program declares it needs the older interpretation is just to have the 
appropriate "use 5" and NOT some "use compat::perl5".

The best way to conceptualize all this is that there exists a variety of Perl 
(primary) dialects and each dialect is named with a number such as 5.8 or 5.30 
or 7.0 or whatever.  And so the "use N" line is an explicit declaration by the 
Perl file is that it conforms to that specific dialect and that it should be 
interpreted according to the syntax and semantics of that dialect.

The authors of the Perl file are explicitly saying that they know the file 
conforms to that specific Perl dialect.  The Perl MAY also conform to other Perl 
dialects but the authors are not making any explicit assertion about this.  A 
reasonable implication given Perl history is that the Perl file is likely 
compatible with later dialects and unlikely compatible with earlier ones, but 
the stated version is the only one we know for sure.

Explicit versioning in the Perl code provides greater stability and 
forwards/backwards compatibility than having no version declaration.  Anyone 
looking at it always knows what they're dealing with, what the author's intent was.

By simply requiring AN explicit version declaration, it is trivially easy to 
make a Perl file compatible with Perl 7 while still also being compatible with 
Perl 5, or likewise for any other versions, because it is written to a common 
subset.

We do NOT want to be forking CPAN, generally.  The smallest change to make sure 
its compatible with Perl 7 while still also being compatible with Perl 5 is to 
ensure it has "use 5" if it didn't already.  As long as CPAN authors don't need 
features introduced in Perl 7, their modules can still be usable with older Perl 
interpreters but also be usable with Perl 7.  They just change to "use 7" when 
they want to require Perl 7.

There is no reason that Baby Perl can't include the 1-liner "use N", that gets 
people used to explicit versioning right from the start.  We just need to 
explain to users that the number has an actual meaning and higher numbers 
generally mean more features, and that it isn't just some opaque constant that 
you set once and never change.  Later on, they can increase the numbers at the 
same time they discover the existence of new features that require it; any news 
or teachable moment that informs on the existence of a new feature also says 
what dialect/Perl version is needed at a minimum to obtain it.

So making "use 5" mandatory is no worse than requiring "use compat::perl5" but 
its more terse and more future-proof and also a lot of code would already conform.

Sure, a lot or even a majority of extant Perl 5 code may not have any "use 5" 
and it may have largely been ignored, but this is a behavior we can change and 
have people learn.  And they would learn best when the Perl interpreter straight 
out tells them to add this when they don't have it.

The error message would basically say:

* Perl file X needs to declare a Perl language version that it conforms to, with 
a line like "use N;" for example "use 7.0;".

... where the example is the version of the current interpreter giving said error.

If we want to help ease people into this new paradigm of mandatory versions, we 
could first release a major Perl version that just emits that message as a 
non-suppressible warning, and then the subsequent major version could make it 
fatal.  The former could be 5.34 and the latter be 7.0.

Now I've seen a number of concerns that explicitly saying "use 7.0" means "turn 
ALL the features on", but I disagree with that.

Rather, saying "use 7.0" should mean nothing more than set the knobs the way 
they were intended to be as the defaults for Perl 7.  So whatever default 
behavior was intended for Perl 7 when there was no "use 7" line, make exactly 
what you get when you DO say "use 7".

So "use 7" means the more conservative default settings, which exclude the 
problematic ones, and people can still activate the riskier ones separately.

Now the existing tools and plans to help with migration of Perl code to the 
version 7 dialect or tools to help deal with CPAN modules can all still happen 
as proposed.

But the idea of zero boilerplate should be abandoned, and the simple "use N" 
boilerplate be made mandatory instead.

For now I will basically end by quoting what Philippe said earlier; he seemed to 
have much the same proposal that I do, but I explained it differently above.

On 2020 June 25 Philippe Bruhat said:
> In my understanding, the goal of the new Perl is to cut off the
> maintenance burden of the old code.
> 
> Both Perl code on the outside and code inside perl.  
> 
> Having old code run unmodified under Perl 7 doesn't achieve that,
> as newer Perls will have to support unqualified Perl code forever.
> 
> I think there's a very simple way to:
> - make Perl 7 code not work under perl5
> - make Perl 5 code stop working under perl7
> 
> And this way is: `use v7`, but _mandatory_.
> Make newer Perls _demand_ you know which version your code target.
> 
> If all Perl 7 code files _have_ to start with `use v7` (still better
> than the dozens of lines of boilerplate Sawyer showed during his talk),
> then:
> 
>     $ cat   perl5-code.pl
>     1;
>     $ perl5 perl5-code.pl
>     $ perl7 perl5-code.pl
>     Unversioned Perl code is not supported--this is v7.0.0, stopped at perl5-code.pl line 1.
>     $ cat   perl7-code.pl
>     use v7;
>     1;
>     $ perl5 perl7-script.pl
>     Perl v7.0.0 required--this is only v5.8.9, stopped at -e line 1.                                                  
>     $ perl7 perl7-code.pl
>     $
> 
> Demanding a `use vX` for any major Perl version after and including 7
> also makes the transition to 8, 9 and 10 much easier. Broken features
> can be dropped between major versions, and the transition to major
> versions has to be conscious. vX can decide how many previous major
> versions it will transparently support.
> 
>     $ perl9 perl7-script.pl
>     Perl v7 code is not supported--this is v9.0.0, supporting Perl versions down to 8.0.0, stopped at perl7-script.pl line 1.                                                  

On an addendum, in response to one person's response, I oppose the idea of new 
filename extensions; we should NOT have pl7 and pm7 or whatever.

Thank you for your consideration.

-- Darren Duncan

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