Front page | perl.perl5.porters |
Postings from June 2020
Re: Announcing Perl 7
From: Darren Duncan
June 27, 2020 08:43
Re: Announcing Perl 7
Message ID: email@example.com
On 2020 June 24 Sawyer X said:
> A little while ago, I gave a talk 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:
> 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
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
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),
> $ cat perl5-code.pl
> $ 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;
> $ 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