Announcing Perl 7

Hi everyone,

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.
* Major versions will be used for two purposes: 1. Turn on features
and pragmas by default, 2. Remove syntax from the language.
* Features will be guarded within a major version (that is, one *must*
enable new features in 7.x with "use feature") but will be turned on
in the next major version.
* Perl 7.0.0 will be the first release. It will effectively be 5.32.0
with a small number of pragmas (at the very least, strict and
warnings) and features. The goal is to make it as trivial as possible
to upgrade from 5.32.0 to 7.0.0.
* Perl 5 will enter a long-term support window - 5+ years. Exact
number not determined yet.
* We intend to release 7.0.0 within a year. However, I am setting the
goal of releasing it before the end of this year. I want to pave the
way for 7.1.0, which will have the stable release of 7.2.0.
* We will introduce utilities to help upgrade code to Perl 7. For
example, if we were to add signatures by default in 7.0.0 (only *for
example*), we will need code that helps users rewrite "sub foo ($)" as
"sub foo :prototype($)".
* We will also introduce a "compat::perl5" module, which will turn
back the defaults of pragmas and features on 5.32.0. With this change,
one could upgrade to Perl 7 binary immediately without changing the
code. It allows a longer upgrade path.
* We will also introduce a module to help fix up other modules. Such a
module will especially help toolchain and infrastructure for CPAN
manage the automatic upgrade or downgrade of modules without the user
having to fix the code they are installing if it's incompatible.

It would be hard to repeat everything in the talk, so I recommend
watching the talk. The short and sweet is: We need to prioritize users
who *write* Perl versus users who explicitly refuse or cannot update
their code. In our current prioritization, we force all existing users
and new users to manage the technical debt of previous generations.

There is *a lot* to figure out at this point. We need to:
* Update the internal code to support "use strict" and "use warnings".
* Bump to 7.0.0.
* Determine which pragmas and features will be enabled and turned on.
* Determine how long we will support Perl version 5.
* Determine the criteria for bumping major versions. Time might not be
the best metric.
* Create tickets for issues to be done so that the community could
help. (People have already reached out, wanting to support this
effort.)
* Make sure we clarify what gets backported to Perl 5.32.x. Right now,
it's the same criteria as every other maint release, except for a much
longer time-frame.
* Work on moving to 7.0.0 is already underway on the p7 branch here:
https://github.com/atoomic/perl

Additional comments:
* Yearly releases for minor versions will continue as planned.
* Monthly releases for dev versions will continue as planned.
* See Perl 7.0.0 as 5.32.0 (+ some new defaults), 7.1.0 as 5.33.1.
7.2.0 will be akin to 5.34.0.
* As exciting as 7.0.0 will be, it will mostly be there just to put us
on our path. 8.0.0 will likely be much exciting.
* There are notable stakeholders to the language which will be working
with us to update their code to 7.0.0 defaults, to help understand the
possible consequences.
* We will need to rename the GitHub repo. That's okay because GitHub
creates an automatic redirect for the URLs, including the GitHub clone
paths.
* /usr/bin/perl is owned by distributions. We are not in charge of it.
We will be providing support to vendors and distributions and help
them reach good decisions and move forward in the manner they choose.

I apologize for not sharing this news earlier. We have been working on
this plan for a very long time. p5p is a public mailing list, and we
needed to manage the communication around this. Despite not being
public, many people worked on it. Vital core developers, numerous core
contributors, several significant stakeholders, vendors/distributions,
and people with an in-depth history in Perl and the core code - were
all involved. We have done a *lot* of work to get to where we are.
While it's not a fully detailed change proposal, we have gone through
quite a lot and tried to be very thorough while leaving room for
things to now be openly discussed.

Several threads will likely begin on the list to address specific
issues listed above. I imagine this thread will itself receive a lot
of responses and soon become sprawling. To manage this, I will open
several threads, over several weeks, so we could have "waves" of
discussions, instead of one monster thread in which we might quickly
lose both our place and our focus. When discussing these topics, I
request people to communicate mindfully and constructively.

I want to thank everyone who helped work on this plan and shape it
into what it is today. These are too many people to mention, but I
want you to know I appreciate the effort, the time, the thorough
reviews, the feedback, the ideas, and the solutions.

Sawyer.

[1] https://www.youtube.com/watch?v=6wPMh-3qYJM
0
xsawyerx
6/24/2020 8:49:30 PM
perl.perl5.porters 48129 articles. 1 followers. Follow

181 Replies
186 Views

Similar Articles

[PageSpeed] 26

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.

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 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.

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.

'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.

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.

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.

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.

So 'use v7' benefits *everyone*: the crusty old coders and the shiny new
coders who know nothing about older perl versions. It's a win-win.

I've seen it suggested that not making v7 the default in some fashion
continues to shackle us an overbearing commitment to backwards
compatibility; but I really can't see this - if I'm missing something
please explain it to me.

Given that the v7 release of the perl interpreter will still have to
support both old and new syntax/semantics regardless (so that whatever
internal flags 'use compat::perl5' sets in the interpreter can suitably
alter the behaviour of the lexer and parser), the choice of default makes
no difference to how hard it is to maintain the interpreter.

In fact by far the biggest issue with backwards compatibility in the
interpreter is XS code, especially XS code which relies on stuff outside
the API (or where its not clear whether its API or not). Nothing in the
perl7 proposal (as far as I'm aware) fixes this - it will still be by far
the biggest millstone around our necks in terms of maintaining and
improving the interpreter.

One of the few remaining selling points of perl5 has been the good
backwards compatibility we've offered. If I were a programmer or company
considering investing in perl for the first time, being told that
my effort now won't get broken in 5-10 years time sounds like a good
thing. If not, I might as well invest in one of the other shiny new
languages with no long-term backcompat guarantee.

To be clear, I am completely happy for a bump in version number to 7;
I just want the default behaviour to be as before in the absence of
'use v7'.


-- 
O Unicef Clearasil!
Gibberish and Drivel!
    -- "Bored of the Rings"
0
davem
6/25/2020 8:16:20 AM
On Thu, Jun 25, 2020 at 09:16:20AM +0100, Dave Mitchell 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 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;

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.                                                  

-- 
 Philippe Bruhat (BooK)

 When you double-cross a friend, you triple-cross yourself.
                                     (Moral from Groo The Wanderer #8 (Epic))
0
book
6/25/2020 12:03:57 PM
--0000000000009f670f05a8eb2b5c
Content-Type: text/plain; charset="UTF-8"

I also want to go on record that I don't disagree with the idea of perl 7
*on principle*; it is certainly a worthy PR exercise if nothing else, as
the attention received outside our normal community is showing. This could
certainly revitalize the idea of Perl as worthy of developer attention in
the modern age.

On Wed, Jun 24, 2020 at 1:49 PM Sawyer X <xsawyerx@gmail.com> wrote:
> * Perl 7.0.0 will be the first release. It will effectively be 5.32.0
> with a small number of pragmas (at the very least, strict and warnings)
and
> features. The goal is to make it as trivial as possible to upgrade from
> 5.32.0 to 7.0.0.

I strongly disagree. We should continue with 5.33.x development (using
the existing version numbering) until (at least) 5.34.0, with the goal of
re-versioning *5.34.0* as 7.0.0.  To release 5.32.0 as 7 would be a mistake
for many reasons, not least of which that the feature list is not finalized
and there has been little to no testing, of which we need a ton.  I can
think of many many different things that need to be smoketested in various
combinations. This is an important release and must be treated with care.

There is also a growing backlog of fixes waiting to be committed to blead,
which I note is *still* not unfrozen from the 5.32.0 release (which hasn't
had its final steps completed either, e.g. the committing of an epigraph,
ticking off of the release, and the switching back from "stable" to
"development" status in numerous config files).

> * We intend to release 7.0.0 within a year.

So we certainly need development releases before then, so 5.32.0 *cannot
possibly* be renumbered as 7.0.0.

> However, I am setting the goal of releasing it before the end of this
> year.

"it will be done by Christmas" is repeating history so hard I have a
concussion. Please let's not do this again.

> There is *a lot* to figure out at this point.

I strongly agree. That's why we can't rush to putting out a 7.0 release
before doing a *lot* of work first.



Karen Etheridge
ether@cpan.org

--0000000000009f670f05a8eb2b5c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon=
t-size:small"><br>I also want to go on record that I don&#39;t disagree wit=
h the idea of perl 7<br>*on principle*; it is certainly a worthy PR exercis=
e if nothing else, as<br>the attention received outside our normal communit=
y is showing. This could<br>certainly revitalize the idea of Perl as worthy=
 of developer attention in<br>the modern age.</div></div><br><div class=3D"=
gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Jun 24, 2020 at =
1:49 PM Sawyer X &lt;<a href=3D"mailto:xsawyerx@gmail.com">xsawyerx@gmail.c=
om</a>&gt; wrote:<br></div><div>&gt; * Perl 7.0.0 will be the first release=
.. It will effectively be 5.32.0<br>&gt; with a small number of pragmas (at =
the very least, strict and warnings) and<br>&gt; features. The goal is to m=
ake it as trivial as possible to upgrade from<br>&gt; 5.32.0 to 7.0.0.<br>=
=C2=A0</div><div>I strongly disagree. We should continue with 5.33.x develo=
pment (using<br>the existing version numbering) until (at least) 5.34.0, wi=
th the goal of<br>re-versioning *5.34.0* as 7.0.0.=C2=A0 To release 5.32.0 =
as 7 would be a mistake<br>for many reasons, not least of which that the fe=
ature list is not finalized<br>and there has been little to no testing, of =
which we need a ton.=C2=A0 I can<br>think of many many different things tha=
t need to be smoketested in various<br>combinations.<span class=3D"gmail_de=
fault" style=3D"font-size:small"> This is an important release and must be =
treated with care.</span><br><br>There is also a growing backlog of fixes w=
aiting to be committed to blead,<br>which I note is *still* not unfrozen fr=
om the 5.32.0 release (which hasn&#39;t<br>had its final steps completed ei=
ther, e.g. the committing of an epigraph,<br>ticking off of the release, an=
d the switching back from &quot;stable&quot; to<br>&quot;development&quot; =
status in numerous config files).<br><br>&gt; * We intend to release 7.0.0 =
within a year.<br><br>So we certainly need development releases before then=
, so 5.32.0 *cannot<br>possibly* be renumbered<span class=3D"gmail_default"=
 style=3D"font-size:small"> as </span>7.0.0.<br><br>&gt; However, I am sett=
ing the goal of releasing it before the end of this<br>&gt; year.<br><br>&q=
uot;it will be done by Christmas&quot; is repeating history so hard I have =
a<br>concussion. Please let&#39;s not do this again.<br><br>&gt; There is *=
a lot* to figure out at this point.<br><br>I strongly agree. That&#39;s why=
 we can&#39;t rush to putting out a 7.0 release<br>before doing a *lot* of =
work first.</div><div><br></div><div><div style=3D"font-size:small" class=
=3D"gmail_default"><br></div><br></div><div><div style=3D"font-size:small" =
class=3D"gmail_default">Karen Etheridge</div><div style=3D"font-size:small"=
 class=3D"gmail_default"><a href=3D"mailto:ether@cpan.org">ether@cpan.org</=
a></div><br></div></div></div>

--0000000000009f670f05a8eb2b5c--
0
perl
6/25/2020 4:34:30 PM
--000000000000baf6de05a8eb5b24
Content-Type: text/plain; charset="UTF-8"

On Thu, Jun 25, 2020 at 4: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.
>
> 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 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.
>
> 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.
>
> '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.
>
> 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.
>
> 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.
>
> 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.
>
> So 'use v7' benefits *everyone*: the crusty old coders and the shiny new
> coders who know nothing about older perl versions. It's a win-win.
>
> I've seen it suggested that not making v7 the default in some fashion
> continues to shackle us an overbearing commitment to backwards
> compatibility; but I really can't see this - if I'm missing something
> please explain it to me.
>
> Given that the v7 release of the perl interpreter will still have to
> support both old and new syntax/semantics regardless (so that whatever
> internal flags 'use compat::perl5' sets in the interpreter can suitably
> alter the behaviour of the lexer and parser), the choice of default makes
> no difference to how hard it is to maintain the interpreter.
>
> In fact by far the biggest issue with backwards compatibility in the
> interpreter is XS code, especially XS code which relies on stuff outside
> the API (or where its not clear whether its API or not). Nothing in the
> perl7 proposal (as far as I'm aware) fixes this - it will still be by far
> the biggest millstone around our necks in terms of maintaining and
> improving the interpreter.
>
> One of the few remaining selling points of perl5 has been the good
> backwards compatibility we've offered. If I were a programmer or company
> considering investing in perl for the first time, being told that
> my effort now won't get broken in 5-10 years time sounds like a good
> thing. If not, I might as well invest in one of the other shiny new
> languages with no long-term backcompat guarantee.
>
> To be clear, I am completely happy for a bump in version number to 7;
> I just want the default behaviour to be as before in the absence of
> 'use v7'.
>

I agree with all points raised here. I think it is a bit of wishful
thinking (?) to equate "nobody knows individual features" with "nobody uses
feature bundles". The feature bundle, to me, is the exact mechanism that we
should be using to solve this problem - it immediately and unambiguously
sets a new lexical base to work with. The major problem so far is that
since v5.12 it has also enabled strict, but it has yet to enable warnings,
meaning any modern code has to also enable warnings, thus generally not
making things any simpler than just enabling strict and warnings yourself
and ignoring the features you don't need.

On top of that, I am not sure what having those features available by
default improves for visibility of them. I only have the benefit of my own
experience, but I cannot think of a case where I did not use a feature
bundle, where I would also be able to update to such a Perl 7 in this
decade. To lay it out, I have three kinds of projects: CPAN, hobby, and
work-related. My CPAN projects support anywhere between 5.8 and 5.16 as a
minimum version depending what is required for them to function. These
obviously cannot take any advantage of either newer feature bundles or Perl
7. My hobby projects currently use the 5.20 feature bundle most commonly,
plus warnings. These easily would use the v7 feature bundle if it existed,
regardless of whether it was default or not. My work project only cares
about the version of Perl it is currently running on, so again, would
easily use the v7 feature bundle once it was planned to run on Perl 7,
regardless of whether it was default or not; and until that point of course
would have no reason to.

The other main issue I have is this argument that we are expending a lot of
effort to cater to this old code. Sure, but this incompatibility does
nothing to solve that. The old features still have to be supported and
deprecated the exact same way as in our current mechanisms. And this is
just pure perl, as mentioned there is no change to how XS APIs are managed.

I also agree that a major version is an extremely important step in terms
of perception, marketing, and visibility. And making it easy to get modern
defaults is an endless personal goal of mine. But I don't think the
incompatibility as proposed provides a benefit worth the cost, when we have
not even explored making feature bundles "complete" by enabling warnings,
or further encouraging their use.

-Dan

--000000000000baf6de05a8eb5b24
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Thu, Jun 25, 2020 at 4:16 AM Dave Mitc=
hell &lt;<a href=3D"mailto:davem@iabyn.com">davem@iabyn.com</a>&gt; wrote:<=
br></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">On Wed, Jun 24, 2020 at 11:49:30PM +0300, Sawyer X wrote:<br>
&gt; * Major versions will be used for two purposes: 1. Turn on features<br=
>
&gt; and pragmas by default, 2. Remove syntax from the language.<br>
<br>
I want to be on the record that I extremely strongly oppose this change.<br=
>
<br>
I think if people want to use the new modern perl, they just put this<br>
one simple line at the top of their code:<br>
<br>
=C2=A0 =C2=A0 use v7;<br>
<br>
this makes everything forward and backwards compatible, and eases the<br>
transition. The thing is that old perl binaries back to at least 5.8.x<br>
recognise this syntax and will produce a helpful error message:<br>
<br>
=C2=A0 =C2=A0 $ perl589 -e&#39;use v7&#39;<br>
=C2=A0 =C2=A0 Perl v7.0.0 required--this is only v5.8.9, stopped at -e line=
 1.<br>
<br>
this helps everyone: writers of perl7 code will know what the problem<br>
is when they accidentally run their code on an old perl binary, rather<br>
than getting some obscure error message.<br>
<br>
Older code continues to run without modification - you don&#39;t<br>
have edit every source file to add a &#39;use compat::perl5&#39; line.<br>
You don&#39;t have to update every existing perl installation to add the<br=
>
compat::perl5 module just so that existing code will continue to run.<br>
CPAN continues to work.<br>
<br>
&#39;use v7&#39; also allows the new stuff to be scoped to a single source =
file;<br>
other .pm files can still be included unmodified using the old perl<br>
syntax.<br>
<br>
Look, we&#39;ve got this great built-in mechanism, &#39;use vx.y.z&#39; tha=
t&#39;s been<br>
around forever. It hasn&#39;t seen much use yet, because frankly there&#39;=
s<br>
been very little call for it, since there hasn&#39;t been much new<br>
non-backcompat stuff so far. But its been sitting there waiting for use to<=
br>
use it.<br>
<br>
In 5 years or whatever, it will also save our bacon when perl8 is<br>
released; suddenly all that source code with &#39;use v7;&#39; at the top w=
ill<br>
continue to work on the perl8 interpreter running in perl7 mode. Rather<br>
than suddenly all breaking.<br>
<br>
It helps IDEs as well - now they can look at a source file and know<br>
instantly what major release of perl this file was written against, and<br>
so how to syntax highlight etc.<br>
<br>
So &#39;use v7&#39; benefits *everyone*: the crusty old coders and the shin=
y new<br>
coders who know nothing about older perl versions. It&#39;s a win-win.<br>
<br>
I&#39;ve seen it suggested that not making v7 the default in some fashion<b=
r>
continues to shackle us an overbearing commitment to backwards<br>
compatibility; but I really can&#39;t see this - if I&#39;m missing somethi=
ng<br>
please explain it to me.<br>
<br>
Given that the v7 release of the perl interpreter will still have to<br>
support both old and new syntax/semantics regardless (so that whatever<br>
internal flags &#39;use compat::perl5&#39; sets in the interpreter can suit=
ably<br>
alter the behaviour of the lexer and parser), the choice of default makes<b=
r>
no difference to how hard it is to maintain the interpreter.<br>
<br>
In fact by far the biggest issue with backwards compatibility in the<br>
interpreter is XS code, especially XS code which relies on stuff outside<br=
>
the API (or where its not clear whether its API or not). Nothing in the<br>
perl7 proposal (as far as I&#39;m aware) fixes this - it will still be by f=
ar<br>
the biggest millstone around our necks in terms of maintaining and<br>
improving the interpreter.<br>
<br>
One of the few remaining selling points of perl5 has been the good<br>
backwards compatibility we&#39;ve offered. If I were a programmer or compan=
y<br>
considering investing in perl for the first time, being told that<br>
my effort now won&#39;t get broken in 5-10 years time sounds like a good<br=
>
thing. If not, I might as well invest in one of the other shiny new<br>
languages with no long-term backcompat guarantee.<br>
<br>
To be clear, I am completely happy for a bump in version number to 7;<br>
I just want the default behaviour to be as before in the absence of<br>
&#39;use v7&#39;.<br></blockquote><div><br></div><div>I agree with all poin=
ts raised here. I think it is a bit of wishful thinking (?) to equate &quot=
;nobody knows individual features&quot; with &quot;nobody uses feature bund=
les&quot;. The feature bundle, to me, is the exact mechanism that we should=
 be using to solve this problem - it immediately and unambiguously sets a n=
ew lexical base to work with. The major problem so far is that since v5.12 =
it has also enabled strict, but it has yet to enable warnings, meaning any =
modern code has to also enable warnings, thus generally not making things a=
ny simpler than just enabling strict and warnings yourself and ignoring the=
 features you don&#39;t need.</div><div><br></div><div>On top of that, I am=
 not sure what having those features available by default improves for visi=
bility of them. I only have the benefit of my own experience, but I cannot =
think of a case where I did not use a feature bundle, where I would also be=
 able to update to such a Perl 7 in this decade. To lay it out, I have thre=
e kinds of projects: CPAN, hobby, and work-related. My CPAN projects suppor=
t anywhere between 5.8 and 5.16 as a minimum version depending what is requ=
ired for them to function. These obviously cannot take any advantage of eit=
her newer feature bundles or Perl 7. My hobby projects currently use the 5.=
20 feature bundle most commonly, plus warnings. These easily would use the =
v7 feature bundle if it existed, regardless of whether it was default or no=
t. My work project only cares about the version of Perl it is currently run=
ning on, so again, would easily use the v7 feature bundle once it was plann=
ed to run on Perl 7, regardless of whether it was default or not; and until=
 that point of course would have no reason to.</div><div><br></div><div>The=
 other main issue I have is this argument that we are expending a lot of ef=
fort to cater to this old code. Sure, but this incompatibility does nothing=
 to solve that. The old features still have to be supported and deprecated =
the exact same way as in our current mechanisms. And this is just pure perl=
, as mentioned there is no change to how XS APIs are managed.</div><div><br=
></div><div>I also agree that a major version is an extremely important ste=
p in terms of perception, marketing, and visibility. And making it easy to =
get modern defaults is an endless personal goal of mine. But I don&#39;t th=
ink the incompatibility as proposed provides a benefit worth the cost, when=
 we have not even explored making feature bundles &quot;complete&quot; by e=
nabling warnings, or further encouraging their use.</div><div><br></div><di=
v>-Dan</div></div></div>

--000000000000baf6de05a8eb5b24--
0
grinnz
6/25/2020 4:47:50 PM
--00000000000021745605a8eb8ab2
Content-Type: text/plain; charset="UTF-8"

I'll also agree with efforts to revitalise the community and language, and
take similar issue to the previous points.

I don't think the defaults for .pl, .pm, or non-extension files can change.
However, .pl7 and .pm7 files could default to perl 7 features. Hopefully
including warnings.

Otherwise, I don't see a world in which I would be happy that my distro
upgraded its perl to perl7 on me. It would break all my other stuff that
I'm running. And likely would break every perl script that comes with the
system, which means they wouldn't be able to upgrade to perl7 anyway once
cups et al stopped working.

If the executable is going to be /usr/bin/perl, it should run perl without
breaking everything. If it's going to be /usr/bin/p7, then, sure, whatever,
perl and p7 can coexist.

I don't want to see another python2-to-3 migration. My distro is still
trying to get past that one.

On Thu, Jun 25, 2020 at 10:48 AM Dan Book <grinnz@gmail.com> wrote:

> On Thu, Jun 25, 2020 at 4: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.
>>
>> 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 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.
>>
>> 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.
>>
>> '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.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> So 'use v7' benefits *everyone*: the crusty old coders and the shiny new
>> coders who know nothing about older perl versions. It's a win-win.
>>
>> I've seen it suggested that not making v7 the default in some fashion
>> continues to shackle us an overbearing commitment to backwards
>> compatibility; but I really can't see this - if I'm missing something
>> please explain it to me.
>>
>> Given that the v7 release of the perl interpreter will still have to
>> support both old and new syntax/semantics regardless (so that whatever
>> internal flags 'use compat::perl5' sets in the interpreter can suitably
>> alter the behaviour of the lexer and parser), the choice of default makes
>> no difference to how hard it is to maintain the interpreter.
>>
>> In fact by far the biggest issue with backwards compatibility in the
>> interpreter is XS code, especially XS code which relies on stuff outside
>> the API (or where its not clear whether its API or not). Nothing in the
>> perl7 proposal (as far as I'm aware) fixes this - it will still be by far
>> the biggest millstone around our necks in terms of maintaining and
>> improving the interpreter.
>>
>> One of the few remaining selling points of perl5 has been the good
>> backwards compatibility we've offered. If I were a programmer or company
>> considering investing in perl for the first time, being told that
>> my effort now won't get broken in 5-10 years time sounds like a good
>> thing. If not, I might as well invest in one of the other shiny new
>> languages with no long-term backcompat guarantee.
>>
>> To be clear, I am completely happy for a bump in version number to 7;
>> I just want the default behaviour to be as before in the absence of
>> 'use v7'.
>>
>
> I agree with all points raised here. I think it is a bit of wishful
> thinking (?) to equate "nobody knows individual features" with "nobody uses
> feature bundles". The feature bundle, to me, is the exact mechanism that we
> should be using to solve this problem - it immediately and unambiguously
> sets a new lexical base to work with. The major problem so far is that
> since v5.12 it has also enabled strict, but it has yet to enable warnings,
> meaning any modern code has to also enable warnings, thus generally not
> making things any simpler than just enabling strict and warnings yourself
> and ignoring the features you don't need.
>
> On top of that, I am not sure what having those features available by
> default improves for visibility of them. I only have the benefit of my own
> experience, but I cannot think of a case where I did not use a feature
> bundle, where I would also be able to update to such a Perl 7 in this
> decade. To lay it out, I have three kinds of projects: CPAN, hobby, and
> work-related. My CPAN projects support anywhere between 5.8 and 5.16 as a
> minimum version depending what is required for them to function. These
> obviously cannot take any advantage of either newer feature bundles or Perl
> 7. My hobby projects currently use the 5.20 feature bundle most commonly,
> plus warnings. These easily would use the v7 feature bundle if it existed,
> regardless of whether it was default or not. My work project only cares
> about the version of Perl it is currently running on, so again, would
> easily use the v7 feature bundle once it was planned to run on Perl 7,
> regardless of whether it was default or not; and until that point of course
> would have no reason to.
>
> The other main issue I have is this argument that we are expending a lot
> of effort to cater to this old code. Sure, but this incompatibility does
> nothing to solve that. The old features still have to be supported and
> deprecated the exact same way as in our current mechanisms. And this is
> just pure perl, as mentioned there is no change to how XS APIs are managed.
>
> I also agree that a major version is an extremely important step in terms
> of perception, marketing, and visibility. And making it easy to get modern
> defaults is an endless personal goal of mine. But I don't think the
> incompatibility as proposed provides a benefit worth the cost, when we have
> not even explored making feature bundles "complete" by enabling warnings,
> or further encouraging their use.
>
> -Dan
>

--00000000000021745605a8eb8ab2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I&#39;ll also agree with efforts to revitalise the co=
mmunity and language, and take similar issue to the previous points.</div><=
div><br></div>I don&#39;t think the defaults for .pl, .pm, or non-extension=
 files can change. However, .pl7 and .pm7 files could default to perl 7 fea=
tures. Hopefully including warnings.<div><br></div><div>Otherwise, I don&#3=
9;t see a world in which I would be happy that my distro upgraded its perl =
to perl7 on me. It would break all my other stuff that I&#39;m running. And=
 likely would break every perl script that comes with the system, which mea=
ns they wouldn&#39;t be able to upgrade to perl7 anyway once cups et al sto=
pped working.</div><div><br></div><div>If the executable is going to be /us=
r/bin/perl, it should run perl without breaking everything. If it&#39;s goi=
ng to be /usr/bin/p7, then, sure, whatever, perl and p7 can coexist.</div><=
div><br></div><div>I don&#39;t want to see another python2-to-3 migration. =
My distro is still trying to get past that one.</div></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Jun 25, 2020=
 at 10:48 AM Dan Book &lt;<a href=3D"mailto:grinnz@gmail.com">grinnz@gmail.=
com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x"><div dir=3D"ltr"><div dir=3D"ltr">On Thu, Jun 25, 2020 at 4:16 AM Dave M=
itchell &lt;<a href=3D"mailto:davem@iabyn.com" target=3D"_blank">davem@iaby=
n.com</a>&gt; wrote:<br></div><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">On Wed, Jun 24, 2020 at 11:49:30PM +0300, =
Sawyer X wrote:<br>
&gt; * Major versions will be used for two purposes: 1. Turn on features<br=
>
&gt; and pragmas by default, 2. Remove syntax from the language.<br>
<br>
I want to be on the record that I extremely strongly oppose this change.<br=
>
<br>
I think if people want to use the new modern perl, they just put this<br>
one simple line at the top of their code:<br>
<br>
=C2=A0 =C2=A0 use v7;<br>
<br>
this makes everything forward and backwards compatible, and eases the<br>
transition. The thing is that old perl binaries back to at least 5.8.x<br>
recognise this syntax and will produce a helpful error message:<br>
<br>
=C2=A0 =C2=A0 $ perl589 -e&#39;use v7&#39;<br>
=C2=A0 =C2=A0 Perl v7.0.0 required--this is only v5.8.9, stopped at -e line=
 1.<br>
<br>
this helps everyone: writers of perl7 code will know what the problem<br>
is when they accidentally run their code on an old perl binary, rather<br>
than getting some obscure error message.<br>
<br>
Older code continues to run without modification - you don&#39;t<br>
have edit every source file to add a &#39;use compat::perl5&#39; line.<br>
You don&#39;t have to update every existing perl installation to add the<br=
>
compat::perl5 module just so that existing code will continue to run.<br>
CPAN continues to work.<br>
<br>
&#39;use v7&#39; also allows the new stuff to be scoped to a single source =
file;<br>
other .pm files can still be included unmodified using the old perl<br>
syntax.<br>
<br>
Look, we&#39;ve got this great built-in mechanism, &#39;use vx.y.z&#39; tha=
t&#39;s been<br>
around forever. It hasn&#39;t seen much use yet, because frankly there&#39;=
s<br>
been very little call for it, since there hasn&#39;t been much new<br>
non-backcompat stuff so far. But its been sitting there waiting for use to<=
br>
use it.<br>
<br>
In 5 years or whatever, it will also save our bacon when perl8 is<br>
released; suddenly all that source code with &#39;use v7;&#39; at the top w=
ill<br>
continue to work on the perl8 interpreter running in perl7 mode. Rather<br>
than suddenly all breaking.<br>
<br>
It helps IDEs as well - now they can look at a source file and know<br>
instantly what major release of perl this file was written against, and<br>
so how to syntax highlight etc.<br>
<br>
So &#39;use v7&#39; benefits *everyone*: the crusty old coders and the shin=
y new<br>
coders who know nothing about older perl versions. It&#39;s a win-win.<br>
<br>
I&#39;ve seen it suggested that not making v7 the default in some fashion<b=
r>
continues to shackle us an overbearing commitment to backwards<br>
compatibility; but I really can&#39;t see this - if I&#39;m missing somethi=
ng<br>
please explain it to me.<br>
<br>
Given that the v7 release of the perl interpreter will still have to<br>
support both old and new syntax/semantics regardless (so that whatever<br>
internal flags &#39;use compat::perl5&#39; sets in the interpreter can suit=
ably<br>
alter the behaviour of the lexer and parser), the choice of default makes<b=
r>
no difference to how hard it is to maintain the interpreter.<br>
<br>
In fact by far the biggest issue with backwards compatibility in the<br>
interpreter is XS code, especially XS code which relies on stuff outside<br=
>
the API (or where its not clear whether its API or not). Nothing in the<br>
perl7 proposal (as far as I&#39;m aware) fixes this - it will still be by f=
ar<br>
the biggest millstone around our necks in terms of maintaining and<br>
improving the interpreter.<br>
<br>
One of the few remaining selling points of perl5 has been the good<br>
backwards compatibility we&#39;ve offered. If I were a programmer or compan=
y<br>
considering investing in perl for the first time, being told that<br>
my effort now won&#39;t get broken in 5-10 years time sounds like a good<br=
>
thing. If not, I might as well invest in one of the other shiny new<br>
languages with no long-term backcompat guarantee.<br>
<br>
To be clear, I am completely happy for a bump in version number to 7;<br>
I just want the default behaviour to be as before in the absence of<br>
&#39;use v7&#39;.<br></blockquote><div><br></div><div>I agree with all poin=
ts raised here. I think it is a bit of wishful thinking (?) to equate &quot=
;nobody knows individual features&quot; with &quot;nobody uses feature bund=
les&quot;. The feature bundle, to me, is the exact mechanism that we should=
 be using to solve this problem - it immediately and unambiguously sets a n=
ew lexical base to work with. The major problem so far is that since v5.12 =
it has also enabled strict, but it has yet to enable warnings, meaning any =
modern code has to also enable warnings, thus generally not making things a=
ny simpler than just enabling strict and warnings yourself and ignoring the=
 features you don&#39;t need.</div><div><br></div><div>On top of that, I am=
 not sure what having those features available by default improves for visi=
bility of them. I only have the benefit of my own experience, but I cannot =
think of a case where I did not use a feature bundle, where I would also be=
 able to update to such a Perl 7 in this decade. To lay it out, I have thre=
e kinds of projects: CPAN, hobby, and work-related. My CPAN projects suppor=
t anywhere between 5.8 and 5.16 as a minimum version depending what is requ=
ired for them to function. These obviously cannot take any advantage of eit=
her newer feature bundles or Perl 7. My hobby projects currently use the 5.=
20 feature bundle most commonly, plus warnings. These easily would use the =
v7 feature bundle if it existed, regardless of whether it was default or no=
t. My work project only cares about the version of Perl it is currently run=
ning on, so again, would easily use the v7 feature bundle once it was plann=
ed to run on Perl 7, regardless of whether it was default or not; and until=
 that point of course would have no reason to.</div><div><br></div><div>The=
 other main issue I have is this argument that we are expending a lot of ef=
fort to cater to this old code. Sure, but this incompatibility does nothing=
 to solve that. The old features still have to be supported and deprecated =
the exact same way as in our current mechanisms. And this is just pure perl=
, as mentioned there is no change to how XS APIs are managed.</div><div><br=
></div><div>I also agree that a major version is an extremely important ste=
p in terms of perception, marketing, and visibility. And making it easy to =
get modern defaults is an endless personal goal of mine. But I don&#39;t th=
ink the incompatibility as proposed provides a benefit worth the cost, when=
 we have not even explored making feature bundles &quot;complete&quot; by e=
nabling warnings, or further encouraging their use.</div><div><br></div><di=
v>-Dan</div></div></div>
</blockquote></div>

--00000000000021745605a8eb8ab2--
0
tanktalus
6/25/2020 5:01:00 PM
On Wed, Jun 24, 2020 at 11:49:30PM +0300, Sawyer X wrote:
>I apologize for not sharing this news earlier. We have been working on 
>this plan for a very long time. p5p is a public mailing list, and we 
>needed to manage the communication around this. Despite not being 
>public, many people worked on it.

First-time poster here.

I think not having discussed this in public risks setting a really bad 
precedent.  I had been taking a break from lurking on perl5-porters, so 
when the news was announced on perl.com, I assumed it had been being 
discussed on here and that I'd simply missed it, and was very surprised 
to find this announcement.  Can you please elaborate on "we needed to 
manage the communication around this"?

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.

-- 
Tom Ryder <https://sanctum.geek.nz/>
Maybe we can bring back the light.
0
perl5
6/25/2020 9:52:29 PM
Wow.  I haven't been paying as much attention lately as I would have
liked but it seems the biggest thing I missed wasn't actually
discussed publicly.  There have been a lot of good points in this
thread already.

I agree with Karen that the earliest that a change of this magnitude
should be considered for release is at the time of the next annual
release, i.e., 7.0.0 comes right after 5.33.11 and we spend a year
talking about why it's 7.0.0 instead of 5.34.0 and testing everything
to see if it can actually work.  (I suppose one could consider 6.9.x
for the development releases this year just to shake out version
number problems, but that's fodder for another discussion).

I agree with Dave that it would be a bad idea to simply enable umpteen
years' worth of feature pragmas in one fell swoop with a year or less
of warning.  Dave has another good point that long support windows are
a distinguishing feature of Perl that few packages provide these days
(don't get me started on Polymer).

I do think it's reasonable to say that version-specific feature
bundles become the default in some well-defined (lengthy) time window.
So for example, the equivalent of "use v7;" becomes available
immediately in 7.0.0 via the pragma but on by default in Perl 10.0.0
or 12.0.0, or something.  As far as enablement, it's a sort of
anti-deprecation cycle.  But it should be defined in terms of
deprecation as well, where appropriate, such that things that get
turned on by default in, for example, 12.0.0, dictate that the older
alternatives are removed entirely from the language in 17.0.0 (or
something -- the right number of years is, again, a separate
discussion).  Finding ways to get rid of stuff that never really
worked quite right and has given everyone a headache who tried to fix
it should be an explicit goal of such a feature cycle.

Basically, my position is that if we change our minds about how people
should use Perl we should give them a long, clear window in which to
sort out what they need to do differently.
0
craig
6/25/2020 11:38:19 PM
I don't understand many of the objections.  No one is going to force 
people to move off 5.32, and we are promising a 5-10 year support 
window.  I think that is ample.

But let me cut to the chase.  I'm unclear as to what the tasks needed 
to move to 7 are, and who is going to be doing the work on them.  I 
don't see how there would be much to do in the C code of the core, where 
I spend most of my time.

I suggest we fork, and have a 5.33 repository, and a pre-7 repository. 
And then we can see where we are as the year progresses.  We would 
cherry pick from the alternate repository as we go along.

I would think the pre-7 changes would first be just adding the 
appropriate pragma calls, which later would become noops.  I have run 
for years the test suite with PERL5OPT=-w.  There used to be a lot of 
scary warnings come out, but almost all of those have been fixed over time.

Various portions of perl code in the 5.33 series could be considered 
off-limits until the 7 series had fixed it.  We could do an audit of 
code that already have the intended pragmas in the correct state, and 
whitelist them.

I also need some examples as to why unicode_strings is problematic.  The 
dodgy behavior it fixes can't be what is intended going forward.  Maybe 
the default becomes it goes on, and you can turn it off for binary-like 
data with a renamed 'use bytes'.
0
public
6/26/2020 4:23:47 AM
--00000000000038dcfc05a8f5986c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Jun 26, 2020 at 12:24 AM Karl Williamson <public@khwilliamson.com>
wrote:

> I don't understand many of the objections.  No one is going to force
> people to move off 5.32, and we are promising a 5-10 year support
> window.  I think that is ample.
>

This is unrelated. The objections, at least from my point of view, is the
combination of three factors. Making the new version incompatible breaks
most of CPAN, it will be a huge amount of effort to make it even usable.
Making it incompatible doesn't actually solve most of the issues raised as
motivation for this change. And there are plenty of things that can be done
without making incompatible changes, which simply require someone to do
them. In summary, the concern is that this is introducing unnecessary
breakage that won't solve the problems at hand, especially those it's
purported to help (which I would very much like to help).


> I also need some examples as to why unicode_strings is problematic.  The
> dodgy behavior it fixes can't be what is intended going forward.  Maybe
> the default becomes it goes on, and you can turn it off for binary-like
> data with a renamed 'use bytes'.
>

This would need to be a specific concern of the distribution that runs into
issues. All unicode_strings does is make certain specific string operations
act consistently regardless of whether Perl decided to store a string in
the upgraded or downgraded storage format; without the feature, these
operations use ascii rules on downgraded strings and unicode rules on
upgraded strings, which is noticeable when the string may have non-ascii
characters that can be represented in the downgraded format (such as =C3=A9=
). It
does not require any change to how the contents of strings are used; at
worst it requires rethinking regexes that may be affected by unicode rules.
use bytes is not related, since it causes completely different broken
behavior of using the underlying storage format directly in Perl; you turn
it off to go back to the default heuristic by disabling the unicode_strings
feature.

-Dan

--00000000000038dcfc05a8f5986c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Fri, Jun 26, 2020 at 12:24 AM Karl Wil=
liamson &lt;<a href=3D"mailto:public@khwilliamson.com">public@khwilliamson.=
com</a>&gt; wrote:<br></div><div class=3D"gmail_quote"><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex">I don&#39;t understand many of the objections=
..=C2=A0 No one is going to force <br>
people to move off 5.32, and we are promising a 5-10 year support <br>
window.=C2=A0 I think that is ample.<br></blockquote><div><br></div><div>Th=
is is unrelated. The objections, at least from my point of view, is the com=
bination of three factors. Making the new version incompatible breaks most =
of CPAN, it will be a huge amount of effort to make it even usable. Making =
it incompatible doesn&#39;t actually solve most of the issues raised as mot=
ivation for this change. And there are plenty of things that can be done wi=
thout making incompatible changes, which simply require someone to do them.=
 In summary, the concern is that this is introducing unnecessary breakage t=
hat won&#39;t solve=C2=A0the problems at hand, especially those it&#39;s pu=
rported to help (which I would very much like to help).</div><div>=C2=A0</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex">
I also need some examples as to why unicode_strings is problematic.=C2=A0 T=
he <br>
dodgy behavior it fixes can&#39;t be what is intended going forward.=C2=A0 =
Maybe <br>
the default becomes it goes on, and you can turn it off for binary-like <br=
>
data with a renamed &#39;use bytes&#39;.<br></blockquote><div><br></div><di=
v>This would need to be a specific concern of the distribution that runs in=
to issues. All unicode_strings does is make certain specific string operati=
ons act consistently regardless of whether Perl decided to store a string i=
n the upgraded or downgraded storage format; without the feature, these ope=
rations use ascii rules on downgraded strings and unicode rules on upgraded=
 strings, which is noticeable when the string may have non-ascii characters=
 that can be represented in the downgraded format (such as=C2=A0<span style=
=3D"color:rgb(77,81,86);font-family:Roboto,arial,sans-serif;font-size:14px"=
>=C3=A9</span>). It does not require any change to how the contents of stri=
ngs are used; at worst it requires rethinking regexes that may be affected =
by unicode rules. use bytes is not related, since it causes completely diff=
erent broken behavior of using the underlying storage format directly in Pe=
rl; you turn it off to go back to the default heuristic by disabling the un=
icode_strings feature.</div><div><br></div><div>-Dan</div></div></div>

--00000000000038dcfc05a8f5986c--
0
grinnz
6/26/2020 5:00:35 AM
Karl Williamson <public@khwilliamson.com> wrote:
> I don't understand many of the objections.  No one is going to force people
> to move off 5.32, and we are promising a 5-10 year support window.  I think
> that is ample.

5-10 years is not that long a time, considering many scripts
have been running unchanged since the 90s or early 2000s.

While I'm happy to see my favorite language learning new tricks;
I strongly agree with everything Dave Mitchell said, especially
about "use v7".

Practically every protocol and data format nowadays advertises a
version number, and some of us use SPDX identifiers for licenses.
So think it's reasonable to require "use v7" or "use v8", etc.
in every package that wants new goodies.

I think it'll allow users to adopt new features sooner if it can
be done piecemeal for a large codebase, rather than all at once.

Fwiw, I wasted around 15 years of my life as a Rubyist; and
contributed to the core VM for ~8 of those years.  Every yearly
release was a struggle with deprecations and feature removals.
It never felt like I could build anything that could last
without constant care and feeding.

I still wrote and maintained some Perl throughout that time
(MogileFS and git.git).  It was a much smoother experience.  Not
perfect, but the only Perl incompatibilities I can remember off
the top of my head was a warning for abusing undefined behavior
on "each" and unescaped "{}" in regexps.

> I also need some examples as to why unicode_strings is problematic.  The
> dodgy behavior it fixes can't be what is intended going forward.  Maybe the
> default becomes it goes on, and you can turn it off for binary-like data
> with a renamed 'use bytes'.

I'm no expert in human texts, but it seems the world isn't as
textual, nowadays.  HTTP/2 and HTTP/3 are binary, at least; TLS
is everywhere; and I use pack/unpack/substr a fair amount for
random stuff, especially since I prefer to avoid XS or C.

I've always liked that Perl is close to Unix; especially in the
regard that one can treat everything as a bag-of-bytes.
0
p5p
6/26/2020 7:44:18 AM
--Apple-Mail-0EFD9AC5-C8AB-49C6-BFF3-5EE572A70EFA
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

I think Darin=E2=80=99s idea sounds interesting: have both =E2=80=9Cperl=E2=80=
=9D and =E2=80=9Cperl7=E2=80=9D binaries, with the latter defaulting to the n=
ew goodnesses.

Maybe perl7 could have =E2=80=9Cuse legacy Ancient::CPAN::Module=E2=80=9D to=
 preserve CPAN compatibility?

-Felipe

> On Jun 26, 2020, at 01:10, Darin McBride <tanktalus@gmail.com> wrote:
> =EF=BB=BF
> I'll also agree with efforts to revitalise the community and language, and=
 take similar issue to the previous points.
>=20
> I don't think the defaults for .pl, .pm, or non-extension files can change=
.. However, .pl7 and .pm7 files could default to perl 7 features. Hopefully i=
ncluding warnings.
>=20
> Otherwise, I don't see a world in which I would be happy that my distro up=
graded its perl to perl7 on me. It would break all my other stuff that I'm r=
unning. And likely would break every perl script that comes with the system,=
 which means they wouldn't be able to upgrade to perl7 anyway once cups et a=
l stopped working.
>=20
> If the executable is going to be /usr/bin/perl, it should run perl without=
 breaking everything. If it's going to be /usr/bin/p7, then, sure, whatever,=
 perl and p7 can coexist.
>=20
> I don't want to see another python2-to-3 migration. My distro is still try=
ing to get past that one.
>=20
>> On Thu, Jun 25, 2020 at 10:48 AM Dan Book <grinnz@gmail.com> wrote:
>>> On Thu, Jun 25, 2020 at 4:16 AM Dave Mitchell <davem@iabyn.com> wrote:
>>=20
>>> 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.
>>>=20
>>> I want to be on the record that I extremely strongly oppose this change.=

>>>=20
>>> I think if people want to use the new modern perl, they just put this
>>> one simple line at the top of their code:
>>>=20
>>>     use v7;
>>>=20
>>> 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:
>>>=20
>>>     $ perl589 -e'use v7'
>>>     Perl v7.0.0 required--this is only v5.8.9, stopped at -e line 1.
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> '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.
>>>=20
>>> 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 t=
o
>>> use it.
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> So 'use v7' benefits *everyone*: the crusty old coders and the shiny new=

>>> coders who know nothing about older perl versions. It's a win-win.
>>>=20
>>> I've seen it suggested that not making v7 the default in some fashion
>>> continues to shackle us an overbearing commitment to backwards
>>> compatibility; but I really can't see this - if I'm missing something
>>> please explain it to me.
>>>=20
>>> Given that the v7 release of the perl interpreter will still have to
>>> support both old and new syntax/semantics regardless (so that whatever
>>> internal flags 'use compat::perl5' sets in the interpreter can suitably
>>> alter the behaviour of the lexer and parser), the choice of default make=
s
>>> no difference to how hard it is to maintain the interpreter.
>>>=20
>>> In fact by far the biggest issue with backwards compatibility in the
>>> interpreter is XS code, especially XS code which relies on stuff outside=

>>> the API (or where its not clear whether its API or not). Nothing in the
>>> perl7 proposal (as far as I'm aware) fixes this - it will still be by fa=
r
>>> the biggest millstone around our necks in terms of maintaining and
>>> improving the interpreter.
>>>=20
>>> One of the few remaining selling points of perl5 has been the good
>>> backwards compatibility we've offered. If I were a programmer or company=

>>> considering investing in perl for the first time, being told that
>>> my effort now won't get broken in 5-10 years time sounds like a good
>>> thing. If not, I might as well invest in one of the other shiny new
>>> languages with no long-term backcompat guarantee.
>>>=20
>>> To be clear, I am completely happy for a bump in version number to 7;
>>> I just want the default behaviour to be as before in the absence of
>>> 'use v7'.
>>=20
>> I agree with all points raised here. I think it is a bit of wishful think=
ing (?) to equate "nobody knows individual features" with "nobody uses featu=
re bundles". The feature bundle, to me, is the exact mechanism that we shoul=
d be using to solve this problem - it immediately and unambiguously sets a n=
ew lexical base to work with. The major problem so far is that since v5.12 i=
t has also enabled strict, but it has yet to enable warnings, meaning any mo=
dern code has to also enable warnings, thus generally not making things any s=
impler than just enabling strict and warnings yourself and ignoring the feat=
ures you don't need.
>>=20
>> On top of that, I am not sure what having those features available by def=
ault improves for visibility of them. I only have the benefit of my own expe=
rience, but I cannot think of a case where I did not use a feature bundle, w=
here I would also be able to update to such a Perl 7 in this decade. To lay i=
t out, I have three kinds of projects: CPAN, hobby, and work-related. My CPA=
N projects support anywhere between 5.8 and 5.16 as a minimum version depend=
ing what is required for them to function. These obviously cannot take any a=
dvantage of either newer feature bundles or Perl 7. My hobby projects curren=
tly use the 5.20 feature bundle most commonly, plus warnings. These easily w=
ould use the v7 feature bundle if it existed, regardless of whether it was d=
efault or not. My work project only cares about the version of Perl it is cu=
rrently running on, so again, would easily use the v7 feature bundle once it=
 was planned to run on Perl 7, regardless of whether it was default or not; a=
nd until that point of course would have no reason to.
>>=20
>> The other main issue I have is this argument that we are expending a lot o=
f effort to cater to this old code. Sure, but this incompatibility does noth=
ing to solve that. The old features still have to be supported and deprecate=
d the exact same way as in our current mechanisms. And this is just pure per=
l, as mentioned there is no change to how XS APIs are managed.
>>=20
>> I also agree that a major version is an extremely important step in terms=
 of perception, marketing, and visibility. And making it easy to get modern d=
efaults is an endless personal goal of mine. But I don't think the incompati=
bility as proposed provides a benefit worth the cost, when we have not even e=
xplored making feature bundles "complete" by enabling warnings, or further e=
ncouraging their use.
>>=20
>> -Dan

--Apple-Mail-0EFD9AC5-C8AB-49C6-BFF3-5EE572A70EFA
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div dir=3D"ltr">I think Darin=E2=80=99s id=
ea sounds interesting: have both =E2=80=9Cperl=E2=80=9D and =E2=80=9Cperl7=E2=
=80=9D binaries, with the latter defaulting to the new goodnesses.</div><div=
 dir=3D"ltr"><br></div><div dir=3D"ltr">Maybe perl7 could have =E2=80=9Cuse l=
egacy Ancient::CPAN::Module=E2=80=9D to preserve CPAN compatibility?</div><d=
iv dir=3D"ltr"><br></div><div dir=3D"ltr">-Felipe</div><div dir=3D"ltr"><br>=
<blockquote type=3D"cite">On Jun 26, 2020, at 01:10, Darin McBride &lt;tankt=
alus@gmail.com&gt; wrote:<br></blockquote></div><blockquote type=3D"cite"><d=
iv dir=3D"ltr">=EF=BB=BF<div dir=3D"ltr"><div>I'll also agree with efforts t=
o revitalise the community and language, and take similar issue to the previ=
ous points.</div><div><br></div>I don't think the defaults for .pl, .pm, or n=
on-extension files can change. However, .pl7 and .pm7 files could default to=
 perl 7 features. Hopefully including warnings.<div><br></div><div>Otherwise=
, I don't see a world in which I would be happy that my distro upgraded its p=
erl to perl7 on me. It would break all my other stuff that I'm running. And l=
ikely would break every perl script that comes with the system, which means t=
hey wouldn't be able to upgrade to perl7 anyway once cups et al stopped work=
ing.</div><div><br></div><div>If the executable is going to be /usr/bin/perl=
, it should run perl without breaking everything. If it's going to be /usr/b=
in/p7, then, sure, whatever, perl and p7 can coexist.</div><div><br></div><d=
iv>I don't want to see another python2-to-3 migration. My distro is still tr=
ying to get past that one.</div></div><br><div class=3D"gmail_quote"><div di=
r=3D"ltr" class=3D"gmail_attr">On Thu, Jun 25, 2020 at 10:48 AM Dan Book &lt=
;<a href=3D"mailto:grinnz@gmail.com">grinnz@gmail.com</a>&gt; wrote:<br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div dir=
=3D"ltr">On Thu, Jun 25, 2020 at 4:16 AM Dave Mitchell &lt;<a href=3D"mailto=
:davem@iabyn.com" target=3D"_blank">davem@iabyn.com</a>&gt; wrote:<br></div>=
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=
On Wed, Jun 24, 2020 at 11:49:30PM +0300, Sawyer X wrote:<br>
&gt; * Major versions will be used for two purposes: 1. Turn on features<br>=

&gt; and pragmas by default, 2. Remove syntax from the language.<br>
<br>
I want to be on the record that I extremely strongly oppose this change.<br>=

<br>
I think if people want to use the new modern perl, they just put this<br>
one simple line at the top of their code:<br>
<br>
&nbsp; &nbsp; use v7;<br>
<br>
this makes everything forward and backwards compatible, and eases the<br>
transition. The thing is that old perl binaries back to at least 5.8.x<br>
recognise this syntax and will produce a helpful error message:<br>
<br>
&nbsp; &nbsp; $ perl589 -e'use v7'<br>
&nbsp; &nbsp; Perl v7.0.0 required--this is only v5.8.9, stopped at -e line 1=
..<br>
<br>
this helps everyone: writers of perl7 code will know what the problem<br>
is when they accidentally run their code on an old perl binary, rather<br>
than getting some obscure error message.<br>
<br>
Older code continues to run without modification - you don't<br>
have edit every source file to add a 'use compat::perl5' line.<br>
You don't have to update every existing perl installation to add the<br>
compat::perl5 module just so that existing code will continue to run.<br>
CPAN continues to work.<br>
<br>
'use v7' also allows the new stuff to be scoped to a single source file;<br>=

other .pm files can still be included unmodified using the old perl<br>
syntax.<br>
<br>
Look, we've got this great built-in mechanism, 'use vx.y.z' that's been<br>
around forever. It hasn't seen much use yet, because frankly there's<br>
been very little call for it, since there hasn't been much new<br>
non-backcompat stuff so far. But its been sitting there waiting for use to<b=
r>
use it.<br>
<br>
In 5 years or whatever, it will also save our bacon when perl8 is<br>
released; suddenly all that source code with 'use v7;' at the top will<br>
continue to work on the perl8 interpreter running in perl7 mode. Rather<br>
than suddenly all breaking.<br>
<br>
It helps IDEs as well - now they can look at a source file and know<br>
instantly what major release of perl this file was written against, and<br>
so how to syntax highlight etc.<br>
<br>
So 'use v7' benefits *everyone*: the crusty old coders and the shiny new<br>=

coders who know nothing about older perl versions. It's a win-win.<br>
<br>
I've seen it suggested that not making v7 the default in some fashion<br>
continues to shackle us an overbearing commitment to backwards<br>
compatibility; but I really can't see this - if I'm missing something<br>
please explain it to me.<br>
<br>
Given that the v7 release of the perl interpreter will still have to<br>
support both old and new syntax/semantics regardless (so that whatever<br>
internal flags 'use compat::perl5' sets in the interpreter can suitably<br>
alter the behaviour of the lexer and parser), the choice of default makes<br=
>
no difference to how hard it is to maintain the interpreter.<br>
<br>
In fact by far the biggest issue with backwards compatibility in the<br>
interpreter is XS code, especially XS code which relies on stuff outside<br>=

the API (or where its not clear whether its API or not). Nothing in the<br>
perl7 proposal (as far as I'm aware) fixes this - it will still be by far<br=
>
the biggest millstone around our necks in terms of maintaining and<br>
improving the interpreter.<br>
<br>
One of the few remaining selling points of perl5 has been the good<br>
backwards compatibility we've offered. If I were a programmer or company<br>=

considering investing in perl for the first time, being told that<br>
my effort now won't get broken in 5-10 years time sounds like a good<br>
thing. If not, I might as well invest in one of the other shiny new<br>
languages with no long-term backcompat guarantee.<br>
<br>
To be clear, I am completely happy for a bump in version number to 7;<br>
I just want the default behaviour to be as before in the absence of<br>
'use v7'.<br></blockquote><div><br></div><div>I agree with all points raised=
 here. I think it is a bit of wishful thinking (?) to equate "nobody knows i=
ndividual features" with "nobody uses feature bundles". The feature bundle, t=
o me, is the exact mechanism that we should be using to solve this problem -=
 it immediately and unambiguously sets a new lexical base to work with. The m=
ajor problem so far is that since v5.12 it has also enabled strict, but it h=
as yet to enable warnings, meaning any modern code has to also enable warnin=
gs, thus generally not making things any simpler than just enabling strict a=
nd warnings yourself and ignoring the features you don't need.</div><div><br=
></div><div>On top of that, I am not sure what having those features availab=
le by default improves for visibility of them. I only have the benefit of my=
 own experience, but I cannot think of a case where I did not use a feature b=
undle, where I would also be able to update to such a Perl 7 in this decade.=
 To lay it out, I have three kinds of projects: CPAN, hobby, and work-relate=
d. My CPAN projects support anywhere between 5.8 and 5.16 as a minimum versi=
on depending what is required for them to function. These obviously cannot t=
ake any advantage of either newer feature bundles or Perl 7. My hobby projec=
ts currently use the 5.20 feature bundle most commonly, plus warnings. These=
 easily would use the v7 feature bundle if it existed, regardless of whether=
 it was default or not. My work project only cares about the version of Perl=
 it is currently running on, so again, would easily use the v7 feature bundl=
e once it was planned to run on Perl 7, regardless of whether it was default=
 or not; and until that point of course would have no reason to.</div><div><=
br></div><div>The other main issue I have is this argument that we are expen=
ding a lot of effort to cater to this old code. Sure, but this incompatibili=
ty does nothing to solve that. The old features still have to be supported a=
nd deprecated the exact same way as in our current mechanisms. And this is j=
ust pure perl, as mentioned there is no change to how XS APIs are managed.</=
div><div><br></div><div>I also agree that a major version is an extremely im=
portant step in terms of perception, marketing, and visibility. And making i=
t easy to get modern defaults is an endless personal goal of mine. But I don=
't think the incompatibility as proposed provides a benefit worth the cost, w=
hen we have not even explored making feature bundles "complete" by enabling w=
arnings, or further encouraging their use.</div><div><br></div><div>-Dan</di=
v></div></div>
</blockquote></div>
</div></blockquote></body></html>=

--Apple-Mail-0EFD9AC5-C8AB-49C6-BFF3-5EE572A70EFA--
0
felipe
6/26/2020 10:29:40 AM
On Fri, 26 Jun 2020 at 09:44, Eric Wong <p5p@yhbt.net> wrote:
>
> Karl Williamson <public@khwilliamson.com> wrote:
> > I don't understand many of the objections.  No one is going to force people
> > to move off 5.32, and we are promising a 5-10 year support window.  I think
> > that is ample.
>
> 5-10 years is not that long a time, considering many scripts
> have been running unchanged since the 90s or early 2000s.
>
> While I'm happy to see my favorite language learning new tricks;
> I strongly agree with everything Dave Mitchell said, especially
> about "use v7".

I believe the crunch here is that we want to switch from one model of
development to another. The old model prioritizes keeping old code
running exactly as it used to run. There is merit in that policy. But
there are other workable policies, like some languages basically make
it clear that the language will change and evolve over time and people
using it will have to keep up if they want to use the latest release,
some of the more popular languages around follow this model, so
clearly there is merit in them as well.

Sawyer has made the argument that our current model prioritizes the
wrong party; that it prioritizes the users who do not want to make
perl better, who do not care about perl as a community, but who expect
the community to care about them - after all the only users who are
affected are those expect to be able to run old perl code but also
upgrade to use the latest version of the interpreter. Any user who
wants to keep their software 100% stable can build the older version
of perl. He believes that the other policy leads to a more forward
looking "grow the community" behavior, where old code/language-rules
which is of little use but for a small minority of our users takes
precedence over introducing new features that would make the language
more attractive to a broader audience of devs, and make Perl more
suitable for solving a wider range of problems.

To achieve this change requiring new code to include "use v7" is a
non-starter.  It HAS to be the other way round or the culture wont
change. Everybody will continue to expect that their code without the
'use v7' marker will continue to work as expected, and they will think
that the contract with the perl community remains unchanged. But
Sawyer wants to change the contract *entirely* and requiring an
assertive trigger in the code fatally undermines that intent. He wants
"if you dont tell me what version to run as I will assume you want the
latest feature set always" for a good reason, so that we can tell
people when their code is going to break when we stop supporting
things, and for users who dont help us with that have to own the
breakage. I think this is a lot more reasonable than people are making
out in the discussion so far.

FWIW, I think that what we are doing now isn't working, Perl is dying
out. Sawyer has convinced me it is dying because we have roped
ourselves to dead code and we prioritize the wrong user groups. So I
feel that broad brush he is right and we should go ahead with his
plan. We elected him *exactly* to make these kinds of decisions in the
best interest of the community, of which I feel certain he is trying
to do.

I have to admit I keep wondering if we could use new file extensions
to reduce some of the friction in this process, but I can never figure
out a solution that is really better overall than what Sawyer is
proposing.

Yves
0
demerphq
6/26/2020 12:49:31 PM
--000000000000633b2405a8fced8b
Content-Type: text/plain; charset="UTF-8"

Yves' comments have significantly clarified something for me, which is that
CPAN authors will explicitly specify their Perl version whether we use Dave
Mitchell's idea (users must explicitly "use v7") or Sawyer's idea (user's
get the latest *if they do not use a specific version*). The difference is
how Perl parses a script/module that *does not* specify a version. Under
Dave they get the oldest; under Sawyer they get the newest. CPAN authors
seeking stability will always declare the version of Perl they want. Thus
the boilerplate for any wise CPAN author is still nonzero, but still really
quite small.

This suggests that the meaning of "use v5.20" should perhaps be slightly
revised with the shift to Perl 7. Moving forward we should change the
meaning of this statement so that it allows the feature set that was
available for that version and *disallows* feature sets turned on with new
major version numbers. Thus if I say "use v7.2" in a CPAN module and I
upgrade to Perl 8, my old code will get the feature set from v7.2

As for XS code, I guess a similar approach would need to be taken: you
would have the #define your Perl major and minor version numbers before
#include "perl.h" or something like that. Again, this would require CPAN
authors to dust off their code and add such preprocessor declarations to
their XS codebases, just like they'll need to do for their Perl codebases.

Dave said: "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." I guess my point is that in reality, this
won't happen because all competent CPAN authors will state use v7 at the
top of their modules anyway. All we're really doing here is smoothing the
onboarding path for developers new to Perl.



On Fri, Jun 26, 2020 at 8:49 AM demerphq <demerphq@gmail.com> wrote:

> On Fri, 26 Jun 2020 at 09:44, Eric Wong <p5p@yhbt.net> wrote:
> >
> > Karl Williamson <public@khwilliamson.com> wrote:
> > > I don't understand many of the objections.  No one is going to force
> people
> > > to move off 5.32, and we are promising a 5-10 year support window.  I
> think
> > > that is ample.
> >
> > 5-10 years is not that long a time, considering many scripts
> > have been running unchanged since the 90s or early 2000s.
> >
> > While I'm happy to see my favorite language learning new tricks;
> > I strongly agree with everything Dave Mitchell said, especially
> > about "use v7".
>
> I believe the crunch here is that we want to switch from one model of
> development to another. The old model prioritizes keeping old code
> running exactly as it used to run. There is merit in that policy. But
> there are other workable policies, like some languages basically make
> it clear that the language will change and evolve over time and people
> using it will have to keep up if they want to use the latest release,
> some of the more popular languages around follow this model, so
> clearly there is merit in them as well.
>
> Sawyer has made the argument that our current model prioritizes the
> wrong party; that it prioritizes the users who do not want to make
> perl better, who do not care about perl as a community, but who expect
> the community to care about them - after all the only users who are
> affected are those expect to be able to run old perl code but also
> upgrade to use the latest version of the interpreter. Any user who
> wants to keep their software 100% stable can build the older version
> of perl. He believes that the other policy leads to a more forward
> looking "grow the community" behavior, where old code/language-rules
> which is of little use but for a small minority of our users takes
> precedence over introducing new features that would make the language
> more attractive to a broader audience of devs, and make Perl more
> suitable for solving a wider range of problems.
>
> To achieve this change requiring new code to include "use v7" is a
> non-starter.  It HAS to be the other way round or the culture wont
> change. Everybody will continue to expect that their code without the
> 'use v7' marker will continue to work as expected, and they will think
> that the contract with the perl community remains unchanged. But
> Sawyer wants to change the contract *entirely* and requiring an
> assertive trigger in the code fatally undermines that intent. He wants
> "if you dont tell me what version to run as I will assume you want the
> latest feature set always" for a good reason, so that we can tell
> people when their code is going to break when we stop supporting
> things, and for users who dont help us with that have to own the
> breakage. I think this is a lot more reasonable than people are making
> out in the discussion so far.
>
> FWIW, I think that what we are doing now isn't working, Perl is dying
> out. Sawyer has convinced me it is dying because we have roped
> ourselves to dead code and we prioritize the wrong user groups. So I
> feel that broad brush he is right and we should go ahead with his
> plan. We elected him *exactly* to make these kinds of decisions in the
> best interest of the community, of which I feel certain he is trying
> to do.
>
> I have to admit I keep wondering if we could use new file extensions
> to reduce some of the friction in this process, but I can never figure
> out a solution that is really better overall than what Sawyer is
> proposing.
>
> Yves
>


-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan

--000000000000633b2405a8fced8b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div></div><div>Yves&#39; comments have significantly clar=
ified something for me, which is that CPAN authors will explicitly specify =
their Perl version whether we use Dave Mitchell&#39;s idea (users must expl=
icitly &quot;use v7&quot;) or Sawyer&#39;s idea (user&#39;s get the latest =
<b>if they do not use a specific version</b>). The difference is how Perl p=
arses a script/module that<i> </i>*does not* specify a version. Under Dave =
they get the oldest; under Sawyer they get the newest. CPAN authors seeking=
 stability will always declare the version of Perl they want. Thus the boil=
erplate for any wise CPAN author is still nonzero, but still really quite s=
mall.</div><div><br></div><div>This suggests that the meaning of &quot;use =
v5.20&quot; should perhaps be slightly revised with the shift to Perl 7. Mo=
ving forward we should change the meaning of this statement so that it allo=
ws <b></b>the feature set that was available for that version and *disallow=
s*  feature sets turned on with new major version numbers. Thus if I say &q=
uot;use v7.2&quot; in a CPAN module and I upgrade to Perl 8, my old code wi=
ll get the feature set from v7.2<br></div><div><br></div><div>As for XS cod=
e, I guess a similar approach would need to be taken: you would have the #d=
efine your Perl major and minor version numbers before #include &quot;perl.=
h&quot; or something like that. Again, this would require CPAN authors to d=
ust off their code and add such preprocessor declarations to their XS codeb=
ases, just like they&#39;ll need to do for their Perl codebases.</div><div>=
<br></div><div>Dave said: &quot;In 5 years or whatever, it will also save o=
ur bacon when perl8 is released; suddenly all that source code with &#39;us=
e v7;&#39; at the top will continue to work on the perl8 interpreter runnin=
g in perl7 mode. Rather than suddenly all breaking.&quot; I guess my point =
is that in reality, this won&#39;t happen because all competent CPAN author=
s will state use v7 at the top of their modules anyway. All we&#39;re reall=
y doing here is smoothing the onboarding path for developers new to Perl.<b=
r></div><div><br></div><div><br></div></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Fri, Jun 26, 2020 at 8:49 AM demer=
phq &lt;<a href=3D"mailto:demerphq@gmail.com">demerphq@gmail.com</a>&gt; wr=
ote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, 26 =
Jun 2020 at 09:44, Eric Wong &lt;<a href=3D"mailto:p5p@yhbt.net" target=3D"=
_blank">p5p@yhbt.net</a>&gt; wrote:<br>
&gt;<br>
&gt; Karl Williamson &lt;<a href=3D"mailto:public@khwilliamson.com" target=
=3D"_blank">public@khwilliamson.com</a>&gt; wrote:<br>
&gt; &gt; I don&#39;t understand many of the objections.=C2=A0 No one is go=
ing to force people<br>
&gt; &gt; to move off 5.32, and we are promising a 5-10 year support window=
..=C2=A0 I think<br>
&gt; &gt; that is ample.<br>
&gt;<br>
&gt; 5-10 years is not that long a time, considering many scripts<br>
&gt; have been running unchanged since the 90s or early 2000s.<br>
&gt;<br>
&gt; While I&#39;m happy to see my favorite language learning new tricks;<b=
r>
&gt; I strongly agree with everything Dave Mitchell said, especially<br>
&gt; about &quot;use v7&quot;.<br>
<br>
I believe the crunch here is that we want to switch from one model of<br>
development to another. The old model prioritizes keeping old code<br>
running exactly as it used to run. There is merit in that policy. But<br>
there are other workable policies, like some languages basically make<br>
it clear that the language will change and evolve over time and people<br>
using it will have to keep up if they want to use the latest release,<br>
some of the more popular languages around follow this model, so<br>
clearly there is merit in them as well.<br>
<br>
Sawyer has made the argument that our current model prioritizes the<br>
wrong party; that it prioritizes the users who do not want to make<br>
perl better, who do not care about perl as a community, but who expect<br>
the community to care about them - after all the only users who are<br>
affected are those expect to be able to run old perl code but also<br>
upgrade to use the latest version of the interpreter. Any user who<br>
wants to keep their software 100% stable can build the older version<br>
of perl. He believes that the other policy leads to a more forward<br>
looking &quot;grow the community&quot; behavior, where old code/language-ru=
les<br>
which is of little use but for a small minority of our users takes<br>
precedence over introducing new features that would make the language<br>
more attractive to a broader audience of devs, and make Perl more<br>
suitable for solving a wider range of problems.<br>
<br>
To achieve this change requiring new code to include &quot;use v7&quot; is =
a<br>
non-starter.=C2=A0 It HAS to be the other way round or the culture wont<br>
change. Everybody will continue to expect that their code without the<br>
&#39;use v7&#39; marker will continue to work as expected, and they will th=
ink<br>
that the contract with the perl community remains unchanged. But<br>
Sawyer wants to change the contract *entirely* and requiring an<br>
assertive trigger in the code fatally undermines that intent. He wants<br>
&quot;if you dont tell me what version to run as I will assume you want the=
<br>
latest feature set always&quot; for a good reason, so that we can tell<br>
people when their code is going to break when we stop supporting<br>
things, and for users who dont help us with that have to own the<br>
breakage. I think this is a lot more reasonable than people are making<br>
out in the discussion so far.<br>
<br>
FWIW, I think that what we are doing now isn&#39;t working, Perl is dying<b=
r>
out. Sawyer has convinced me it is dying because we have roped<br>
ourselves to dead code and we prioritize the wrong user groups. So I<br>
feel that broad brush he is right and we should go ahead with his<br>
plan. We elected him *exactly* to make these kinds of decisions in the<br>
best interest of the community, of which I feel certain he is trying<br>
to do.<br>
<br>
I have to admit I keep wondering if we could use new file extensions<br>
to reduce some of the friction in this process, but I can never figure<br>
out a solution that is really better overall than what Sawyer is<br>
proposing.<br>
<br>
Yves<br>
</blockquote></div><br clear=3D"all"><br>-- <br><div dir=3D"ltr" class=3D"g=
mail_signature">=C2=A0&quot;Debugging is twice as hard as writing the code =
in the first place.<br>
 =C2=A0 Therefore, if you write the code as cleverly as possible, you are,<=
br>
 =C2=A0 by definition, not smart enough to debug it.&quot; -- Brian Kernigh=
an<br></div>

--000000000000633b2405a8fced8b--
0
dcmertens
6/26/2020 1:45:40 PM
On Fri, Jun 26, 2020 at 02:49:31PM +0200, demerphq wrote:
> To achieve this change requiring new code to include "use v7" is a
> non-starter.

This is the bit I fundamentally don't understand. Convince me of this,
and most of my objections will fizzle away.

In my world, the big first public release of 7.0.0 will come along with
lots of explanations and docs all saying that "if you are writing modern
perl, then the first thing you need to do is add 'use v7;' to the top of
your script" - in the same way that 'use strict; use warnings' has been
the mantra for the last 20 years.

People learning perl for the first time will know nothing other than to
add 'use v7'. People working for big companies with coding standards
will be told to put 'use v7' at the top of each script.

Meanwhile, people's existing code which doesn't have a 'use vx.y.z' at
the top won't gratuitously break right now.

There is nothing to stop us from, in 5 years say, making the latest
release of of perl putting out an automatic warning along the lines of

    warning: this script doesn't include a 'use vx.y.z'

header, then some time later making it fatal.

Then there's nothing to stop a later release of perl from croaking
if the vx.y.z  doesn't match some minimum we've decided.

There's nothing to stop us in X years time that saying the next release of
perl won't support indirect object syntax or whatever.

In short, lets break things as and when there's a good reason to do so,
rather than break things gratuitously.

As a simple example of the problems enabling stuff by default causes,
here's a little challenge. Write a short script which uses a subroutine
with a prototype. That script must run on both vanilla 5.32.0 and 7.0.0
(by vanilla I mean a perl installation with only the modules installed
that come bundled with perl itself).

Was that easy?

-- 
This email is confidential, and now that you have read it you are legally
obliged to shoot yourself. Or shoot a lawyer, if you prefer. If you have
received this email in error, place it in its original wrapping and return
for a full refund. By opening this email, you accept that Elvis lives.
0
davem
6/26/2020 1:46:10 PM
--00000000000009d8df05a8fd2f1f
Content-Type: text/plain; charset="UTF-8"

Dave,

If my suggestion for the behavior of "use v5.32" are considered good, then
this should work under either 5.32 or 7:

----%<----
use v5.32;
sub say_it ($) {say $_[0]; "foo" }

my @result = say_it 5, 6;
say "result is @result";
---->%----

Amusingly, this is *not* giving me what I expect in my current Perl version
(5.30). I was expecting "5\nresult is foo 6" but I get "5\nresult is foo".

My own misunderstandings about prototypes aside, I think the above is
pretty easy. :-)

David (Mertens)

On Fri, Jun 26, 2020 at 9:46 AM Dave Mitchell <davem@iabyn.com> wrote:

> On Fri, Jun 26, 2020 at 02:49:31PM +0200, demerphq wrote:
> > To achieve this change requiring new code to include "use v7" is a
> > non-starter.
>
> This is the bit I fundamentally don't understand. Convince me of this,
> and most of my objections will fizzle away.
>
> In my world, the big first public release of 7.0.0 will come along with
> lots of explanations and docs all saying that "if you are writing modern
> perl, then the first thing you need to do is add 'use v7;' to the top of
> your script" - in the same way that 'use strict; use warnings' has been
> the mantra for the last 20 years.
>
> People learning perl for the first time will know nothing other than to
> add 'use v7'. People working for big companies with coding standards
> will be told to put 'use v7' at the top of each script.
>
> Meanwhile, people's existing code which doesn't have a 'use vx.y.z' at
> the top won't gratuitously break right now.
>
> There is nothing to stop us from, in 5 years say, making the latest
> release of of perl putting out an automatic warning along the lines of
>
>     warning: this script doesn't include a 'use vx.y.z'
>
> header, then some time later making it fatal.
>
> Then there's nothing to stop a later release of perl from croaking
> if the vx.y.z  doesn't match some minimum we've decided.
>
> There's nothing to stop us in X years time that saying the next release of
> perl won't support indirect object syntax or whatever.
>
> In short, lets break things as and when there's a good reason to do so,
> rather than break things gratuitously.
>
> As a simple example of the problems enabling stuff by default causes,
> here's a little challenge. Write a short script which uses a subroutine
> with a prototype. That script must run on both vanilla 5.32.0 and 7.0.0
> (by vanilla I mean a perl installation with only the modules installed
> that come bundled with perl itself).
>
> Was that easy?
>
> --
> This email is confidential, and now that you have read it you are legally
> obliged to shoot yourself. Or shoot a lawyer, if you prefer. If you have
> received this email in error, place it in its original wrapping and return
> for a full refund. By opening this email, you accept that Elvis lives.
>


-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan

--00000000000009d8df05a8fd2f1f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Dave,</div><div><br></div><div>If my suggestion for t=
he behavior of &quot;use v5.32&quot; are considered good, then this should =
work under either 5.32 or 7:<br></div><div><br></div><div>----%&lt;----</di=
v><div>use v5.32;</div><div>sub say_it ($) {say $_[0]; &quot;foo&quot; }<br=
></div><div><br></div><div>my @result =3D say_it 5, 6;</div><div>say &quot;=
result is @result&quot;;<br></div><div>----&gt;%----</div><div><br></div><d=
iv>Amusingly, this is *not* giving me what I expect in my current Perl vers=
ion (5.30). I was expecting &quot;5\nresult is foo 6&quot; but I get &quot;=
5\nresult is foo&quot;.</div><div><br></div><div>My own misunderstandings a=
bout prototypes aside,  I think the above is pretty easy. :-)<br></div><div=
><br></div><div>David (Mertens)<br></div></div><br><div class=3D"gmail_quot=
e"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Jun 26, 2020 at 9:46 AM Da=
ve Mitchell &lt;<a href=3D"mailto:davem@iabyn.com">davem@iabyn.com</a>&gt; =
wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, J=
un 26, 2020 at 02:49:31PM +0200, demerphq wrote:<br>
&gt; To achieve this change requiring new code to include &quot;use v7&quot=
; is a<br>
&gt; non-starter.<br>
<br>
This is the bit I fundamentally don&#39;t understand. Convince me of this,<=
br>
and most of my objections will fizzle away.<br>
<br>
In my world, the big first public release of 7.0.0 will come along with<br>
lots of explanations and docs all saying that &quot;if you are writing mode=
rn<br>
perl, then the first thing you need to do is add &#39;use v7;&#39; to the t=
op of<br>
your script&quot; - in the same way that &#39;use strict; use warnings&#39;=
 has been<br>
the mantra for the last 20 years.<br>
<br>
People learning perl for the first time will know nothing other than to<br>
add &#39;use v7&#39;. People working for big companies with coding standard=
s<br>
will be told to put &#39;use v7&#39; at the top of each script.<br>
<br>
Meanwhile, people&#39;s existing code which doesn&#39;t have a &#39;use vx.=
y.z&#39; at<br>
the top won&#39;t gratuitously break right now.<br>
<br>
There is nothing to stop us from, in 5 years say, making the latest<br>
release of of perl putting out an automatic warning along the lines of<br>
<br>
=C2=A0 =C2=A0 warning: this script doesn&#39;t include a &#39;use vx.y.z&#3=
9;<br>
<br>
header, then some time later making it fatal.<br>
<br>
Then there&#39;s nothing to stop a later release of perl from croaking<br>
if the vx.y.z=C2=A0 doesn&#39;t match some minimum we&#39;ve decided.<br>
<br>
There&#39;s nothing to stop us in X years time that saying the next release=
 of<br>
perl won&#39;t support indirect object syntax or whatever.<br>
<br>
In short, lets break things as and when there&#39;s a good reason to do so,=
<br>
rather than break things gratuitously.<br>
<br>
As a simple example of the problems enabling stuff by default causes,<br>
here&#39;s a little challenge. Write a short script which uses a subroutine=
<br>
with a prototype. That script must run on both vanilla 5.32.0 and 7.0.0<br>
(by vanilla I mean a perl installation with only the modules installed<br>
that come bundled with perl itself).<br>
<br>
Was that easy?<br>
<br>
-- <br>
This email is confidential, and now that you have read it you are legally<b=
r>
obliged to shoot yourself. Or shoot a lawyer, if you prefer. If you have<br=
>
received this email in error, place it in its original wrapping and return<=
br>
for a full refund. By opening this email, you accept that Elvis lives.<br>
</blockquote></div><br clear=3D"all"><br>-- <br><div dir=3D"ltr" class=3D"g=
mail_signature">=C2=A0&quot;Debugging is twice as hard as writing the code =
in the first place.<br>
 =C2=A0 Therefore, if you write the code as cleverly as possible, you are,<=
br>
 =C2=A0 by definition, not smart enough to debug it.&quot; -- Brian Kernigh=
an<br></div>

--00000000000009d8df05a8fd2f1f--
0
dcmertens
6/26/2020 2:04:01 PM
On Fri, 26 Jun 2020 at 15:45, David Mertens <dcmertens.perl@gmail.com> wrot=
e:
>
> Yves' comments have significantly clarified something for me, which is th=
at CPAN authors will explicitly specify their Perl version whether we use D=
ave Mitchell's idea (users must explicitly "use v7") or Sawyer's idea (user=
's get the latest if they do not use a specific version). The difference is=
 how Perl parses a script/module that *does not* specify a version. Under D=
ave they get the oldest; under Sawyer they get the newest. CPAN authors see=
king stability will always declare the version of Perl they want. Thus the =
boilerplate for any wise CPAN author is still nonzero, but still really qui=
te small.

I may be wrong and the plan has changed since last Sawyer and I
talked, but i believe that the use of "strict" in your code already
triggers the correct assumptions about the code. Thus the affected
code base of this change is the tiny set of scripts which do not use
strict and which expect to have the old behavior.

Since "use strict;" is more or less ubiquitous in most quality code, I
believe the impact of this change will be very limited.

cheers,
Yves
0
demerphq
6/26/2020 2:48:49 PM
On Fri, 26 Jun 2020 at 15:46, Dave Mitchell <davem@iabyn.com> wrote:
>
> On Fri, Jun 26, 2020 at 02:49:31PM +0200, demerphq wrote:
> > To achieve this change requiring new code to include "use v7" is a
> > non-starter.
>
> This is the bit I fundamentally don't understand. Convince me of this,
> and most of my objections will fizzle away.

I think perhaps we are at cross purposes here.

The objective "I wish boilerplate free perl code to stick to the most
modern interpretation of that code" is incompatible with "you must add
boilerplate to get the latest version of the code".

> In my world, the big first public release of 7.0.0 will come along with
> lots of explanations and docs all saying that "if you are writing modern
> perl, then the first thing you need to do is add 'use v7;' to the top of
> your script" - in the same way that 'use strict; use warnings' has been
> the mantra for the last 20 years.
>
> People learning perl for the first time will know nothing other than to
> add 'use v7'. People working for big companies with coding standards
> will be told to put 'use v7' at the top of each script.
>
> Meanwhile, people's existing code which doesn't have a 'use vx.y.z' at
> the top won't gratuitously break right now.

My understanding is any existing code which has "use strict;" will be
fine as "use strict" will be the same "use perl5-semantics" or
whatever the syntaxt will be. Thus relatively little will break. The
code that will break will be scripts like

```
$x= rand();
```

because strict will be implied by default. So that needs to be written:

```
my $x= rand();
```
I think relatively little code will break and that which does which is
important will end up with new maintainers and  new lease on life
because of it.

> There is nothing to stop us from, in 5 years say, making the latest
> release of of perl putting out an automatic warning along the lines of
>
>     warning: this script doesn't include a 'use vx.y.z'
>
> header, then some time later making it fatal.

I don't say you are wrong, but it doesn't achieve the objective Sawyer
wants, which is that baby perl, where you do not specify the semantics
you desire, follows the most modern coding practices.

> Then there's nothing to stop a later release of perl from croaking
> if the vx.y.z  doesn't match some minimum we've decided.
>
> There's nothing to stop us in X years time that saying the next release of
> perl won't support indirect object syntax or whatever.
>
> In short, lets break things as and when there's a good reason to do so,
> rather than break things gratuitously.

I understand what you are saying, but I think saying "gratuitous" is
unfair to Sawyer. I think he is doing this with a good reason and he
has an objective which IMO means it is not gratutious. I understand
you do not feel the objective is worth the cost, but I think it is
unfair to characterize it as gratuitous, and we should be careful not
inflate the scale of that cost. My experience of code at work is that
very little omits use strict and that which does I would be quite
happy to have it start being executed as though strict was on. I doubt
most of it would compile.

So basically to me all you are doing is moving this breakage long into
the future to give all these scripts yet more time to catch up with
modern perl coding practices. I am not convinced its worth the wait. I
think there are relatively few scripts proportionally speaking that do
not use strict, and I think most of the affected existing scripts will
just fail to compile under the new rules, and the ones that do compile
will behave the same as they used to. So I think the scope of this
issue will be relatively small in proportion.

Yves



-- 
perl -Mre=debug -e "/just|another|perl|hacker/"
0
demerphq
6/26/2020 3:10:57 PM
On Fri, Jun 26, 2020 at 05:10:57PM +0200, demerphq wrote:
> My understanding is any existing code which has "use strict;" will be
> fine as "use strict" will be the same "use perl5-semantics" or
> whatever the syntaxt will be. Thus relatively little will break.

This seems to be an important and fundamental disagreement or
misunderstanding between us, and I think it needs resolving before
anything else gets discussed.

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.

For example, disabling indirect object syntax by default will break
all code containing

    my $foo = new Foo(...);

which is still a commonly-used idiom.

Enabling signatures by default will make it nearly impossible to portably
write code which uses subroutine prototypes. (Seriously, try the challenge
I set in my previous email).

Enabling 'use utf8' or 'feature_unicode' by default will silently change
the semantics of code.

etc etc.

-- 
Indomitable in retreat, invincible in advance, insufferable in victory
    -- Churchill on Montgomery
0
davem
6/26/2020 3:29:02 PM
On Fri, 26 Jun 2020 at 17:29, Dave Mitchell <davem@iabyn.com> wrote:
>
> On Fri, Jun 26, 2020 at 05:10:57PM +0200, demerphq wrote:
> > My understanding is any existing code which has "use strict;" will be
> > fine as "use strict" will be the same "use perl5-semantics" or
> > whatever the syntaxt will be. Thus relatively little will break.
>
> This seems to be an important and fundamental disagreement or
> misunderstanding between us, and I think it needs resolving before
> anything else gets discussed.

Ok, so just to be clear, my understanding that "use strict" and "no
strict" will be equivalent to "use perl-5-semantics; use strict;" and
"use perl-5-semantics; no strict;".

Whatever the semantics are. Since most cases people tend to do this:

package Whatever;
use strict;
use warnings;

assuming i am right this is seems to cover making old code continue to
work as though it had been modified to read:

package Whatever;
use perl-5-semantics;
use strict;
use warnings;

> 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.

Yes, unless you request perl-5 semantics by saying "use strict;" or
"use perl-5-semantics;" (however it is spelled in practice)

> I think that this will break a *lot* of existing code and CPAN modules.
> Which is at the heart of my objection.

If I am right about strict do you agree that the scope of breakage
will be much smaller than if I am wrong?

>
> For example, disabling indirect object syntax by default will break
> all code containing
>
>     my $foo = new Foo(...);
>
> which is still a commonly-used idiom.

I don't have that impression. We have none at work for instance.  But
ok. But i think most of it runs inside of `use strict;`

> Enabling signatures by default will make it nearly impossible to portably
> write code which uses subroutine prototypes. (Seriously, try the challenge
> I set in my previous email).

Ill take another look, but again, since I can just say:

  use perl-5-semantics;

then surely it can't be impossible?

> Enabling 'use utf8' or 'feature_unicode' by default will silently change
> the semantics of code.

Again, if this only applies to code not running under use strict I
dont think it will be a big deal.

cheers,
Yves

-- 
perl -Mre=debug -e "/just|another|perl|hacker/"
0
demerphq
6/26/2020 3:50:39 PM
--000000000000b633ab05a8feb763
Content-Type: text/plain; charset="UTF-8"

On Fri, Jun 26, 2020 at 11:51 AM demerphq <demerphq@gmail.com> wrote:

> On Fri, 26 Jun 2020 at 17:29, Dave Mitchell <davem@iabyn.com> wrote:
> >
> > On Fri, Jun 26, 2020 at 05:10:57PM +0200, demerphq wrote:
> > > My understanding is any existing code which has "use strict;" will be
> > > fine as "use strict" will be the same "use perl5-semantics" or
> > > whatever the syntaxt will be. Thus relatively little will break.
> >
> > This seems to be an important and fundamental disagreement or
> > misunderstanding between us, and I think it needs resolving before
> > anything else gets discussed.
>
> Ok, so just to be clear, my understanding that "use strict" and "no
> strict" will be equivalent to "use perl-5-semantics; use strict;" and
> "use perl-5-semantics; no strict;".
>
> Whatever the semantics are. Since most cases people tend to do this:
>
> package Whatever;
> use strict;
> use warnings;
>
> assuming i am right this is seems to cover making old code continue to
> work as though it had been modified to read:
>
> package Whatever;
> use perl-5-semantics;
> use strict;
> use warnings;
>
> > 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.
>
> Yes, unless you request perl-5 semantics by saying "use strict;" or
> "use perl-5-semantics;" (however it is spelled in practice)
>
> > I think that this will break a *lot* of existing code and CPAN modules.
> > Which is at the heart of my objection.
>
> If I am right about strict do you agree that the scope of breakage
> will be much smaller than if I am wrong?
>
> >
> > For example, disabling indirect object syntax by default will break
> > all code containing
> >
> >     my $foo = new Foo(...);
> >
> > which is still a commonly-used idiom.
>
> I don't have that impression. We have none at work for instance.  But
> ok. But i think most of it runs inside of `use strict;`
>
> > Enabling signatures by default will make it nearly impossible to portably
> > write code which uses subroutine prototypes. (Seriously, try the
> challenge
> > I set in my previous email).
>
> Ill take another look, but again, since I can just say:
>
>   use perl-5-semantics;
>
> then surely it can't be impossible?
>
> > Enabling 'use utf8' or 'feature_unicode' by default will silently change
> > the semantics of code.
>
> Again, if this only applies to code not running under use strict I
> dont think it will be a big deal.
>

You seem to be making a lot of fundamental assumptions that are not part of
the proposal.

-Dan

--000000000000b633ab05a8feb763
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Fri, Jun 26, 2020 at 11:51 AM demerphq=
 &lt;<a href=3D"mailto:demerphq@gmail.com">demerphq@gmail.com</a>&gt; wrote=
:<br></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex">On Fri, 26 Jun 2020 at 17:29, Dave Mitchell &lt;<a href=3D"mai=
lto:davem@iabyn.com" target=3D"_blank">davem@iabyn.com</a>&gt; wrote:<br>
&gt;<br>
&gt; On Fri, Jun 26, 2020 at 05:10:57PM +0200, demerphq wrote:<br>
&gt; &gt; My understanding is any existing code which has &quot;use strict;=
&quot; will be<br>
&gt; &gt; fine as &quot;use strict&quot; will be the same &quot;use perl5-s=
emantics&quot; or<br>
&gt; &gt; whatever the syntaxt will be. Thus relatively little will break.<=
br>
&gt;<br>
&gt; This seems to be an important and fundamental disagreement or<br>
&gt; misunderstanding between us, and I think it needs resolving before<br>
&gt; anything else gets discussed.<br>
<br>
Ok, so just to be clear, my understanding that &quot;use strict&quot; and &=
quot;no<br>
strict&quot; will be equivalent to &quot;use perl-5-semantics; use strict;&=
quot; and<br>
&quot;use perl-5-semantics; no strict;&quot;.<br>
<br>
Whatever the semantics are. Since most cases people tend to do this:<br>
<br>
package Whatever;<br>
use strict;<br>
use warnings;<br>
<br>
assuming i am right this is seems to cover making old code continue to<br>
work as though it had been modified to read:<br>
<br>
package Whatever;<br>
use perl-5-semantics;<br>
use strict;<br>
use warnings;<br>
<br>
&gt; My understanding was that, by default, perl7 will enable many of the<b=
r>
&gt; optional features available via &#39;use feature X&#39; and/or &#39;us=
e v5.32.0&#39;,<br>
&gt; plus possibly some other stuff.<br>
<br>
Yes, unless you request perl-5 semantics by saying &quot;use strict;&quot; =
or<br>
&quot;use perl-5-semantics;&quot; (however it is spelled in practice)<br>
<br>
&gt; I think that this will break a *lot* of existing code and CPAN modules=
..<br>
&gt; Which is at the heart of my objection.<br>
<br>
If I am right about strict do you agree that the scope of breakage<br>
will be much smaller than if I am wrong?<br>
<br>
&gt;<br>
&gt; For example, disabling indirect object syntax by default will break<br=
>
&gt; all code containing<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0my $foo =3D new Foo(...);<br>
&gt;<br>
&gt; which is still a commonly-used idiom.<br>
<br>
I don&#39;t have that impression. We have none at work for instance.=C2=A0 =
But<br>
ok. But i think most of it runs inside of `use strict;`<br>
<br>
&gt; Enabling signatures by default will make it nearly impossible to porta=
bly<br>
&gt; write code which uses subroutine prototypes. (Seriously, try the chall=
enge<br>
&gt; I set in my previous email).<br>
<br>
Ill take another look, but again, since I can just say:<br>
<br>
=C2=A0 use perl-5-semantics;<br>
<br>
then surely it can&#39;t be impossible?<br>
<br>
&gt; Enabling &#39;use utf8&#39; or &#39;feature_unicode&#39; by default wi=
ll silently change<br>
&gt; the semantics of code.<br>
<br>
Again, if this only applies to code not running under use strict I<br>
dont think it will be a big deal.<br></blockquote><div><br></div><div>You s=
eem to be making a lot of fundamental assumptions that are not part of the =
proposal.</div><div><br></div><div>-Dan=C2=A0</div></div></div>

--000000000000b633ab05a8feb763--
0
grinnz
6/26/2020 3:53:37 PM
On Fri, 26 Jun 2020 at 17:54, Dan Book <grinnz@gmail.com> wrote:
>
> On Fri, Jun 26, 2020 at 11:51 AM demerphq <demerphq@gmail.com> wrote:
>>
>> On Fri, 26 Jun 2020 at 17:29, Dave Mitchell <davem@iabyn.com> wrote:
>> >
>> > On Fri, Jun 26, 2020 at 05:10:57PM +0200, demerphq wrote:
>> > > My understanding is any existing code which has "use strict;" will be
>> > > fine as "use strict" will be the same "use perl5-semantics" or
>> > > whatever the syntaxt will be. Thus relatively little will break.
>> >
>> > This seems to be an important and fundamental disagreement or
>> > misunderstanding between us, and I think it needs resolving before
>> > anything else gets discussed.
>>
>> Ok, so just to be clear, my understanding that "use strict" and "no
>> strict" will be equivalent to "use perl-5-semantics; use strict;" and
>> "use perl-5-semantics; no strict;".
>>
>> Whatever the semantics are. Since most cases people tend to do this:
>>
>> package Whatever;
>> use strict;
>> use warnings;
>>
>> assuming i am right this is seems to cover making old code continue to
>> work as though it had been modified to read:
>>
>> package Whatever;
>> use perl-5-semantics;
>> use strict;
>> use warnings;
>>
>> > 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.
>>
>> Yes, unless you request perl-5 semantics by saying "use strict;" or
>> "use perl-5-semantics;" (however it is spelled in practice)
>>
>> > I think that this will break a *lot* of existing code and CPAN modules.
>> > Which is at the heart of my objection.
>>
>> If I am right about strict do you agree that the scope of breakage
>> will be much smaller than if I am wrong?
>>
>> >
>> > For example, disabling indirect object syntax by default will break
>> > all code containing
>> >
>> >     my $foo = new Foo(...);
>> >
>> > which is still a commonly-used idiom.
>>
>> I don't have that impression. We have none at work for instance.  But
>> ok. But i think most of it runs inside of `use strict;`
>>
>> > Enabling signatures by default will make it nearly impossible to portably
>> > write code which uses subroutine prototypes. (Seriously, try the challenge
>> > I set in my previous email).
>>
>> Ill take another look, but again, since I can just say:
>>
>>   use perl-5-semantics;
>>
>> then surely it can't be impossible?
>>
>> > Enabling 'use utf8' or 'feature_unicode' by default will silently change
>> > the semantics of code.
>>
>> Again, if this only applies to code not running under use strict I
>> dont think it will be a big deal.
>
>
> You seem to be making a lot of fundamental assumptions that are not part of the proposal.

Im just repeating what I understood from the many discussions I was
involved in with Sawyer about the proposal, it is entirely possible I
am behind on the plan, or that I misunderstood at the time, or that
the proposal somehow missed details that are important to this
discussion.

I have not claimed otherwise either. In my first reply about  this I stated:

"I may be wrong and the plan has changed since last Sawyer and I
talked, but i believe that the use of "strict" in your code already
triggers the correct assumptions about the code."

And I was very careful to say "my understanding" in all my comments.

Yves


-- 
perl -Mre=debug -e "/just|another|perl|hacker/"
0
demerphq
6/26/2020 4:01:07 PM
On Fri, Jun 26, 2020 at 05:50:39PM +0200, demerphq wrote:
> Ok, so just to be clear, my understanding that "use strict" and "no
> strict" will be equivalent to "use perl-5-semantics; use strict;" and
> "use perl-5-semantics; no strict;".

I can't understand your obsession with just 'strict'.

My understanding is that out-of-the-box, a perl7 binary will enable by
default,  *a whole bunch of extra stuff*, not just 'strict'.

So for example,  running a plain perl script using a perl7 interpreter is
as if the following lines had been injected at the top of the script:

    use warnings;
    use strict;
    use feature 'signatures';
    no feature 'indirect';
    ... etc ...

is that the same as your understanding?

-- 
Fire extinguisher (n) a device for holding open fire doors.
0
davem
6/26/2020 4:03:13 PM
-----Original Message-----
From: Dave Mitchell <davem@iabyn.com>=20

> In my world, the big first public release of 7.0.0 will come along with l=
ots of
> explanations and docs all saying that "if you are writing modern perl, th=
en the
> first thing you need to do is add 'use v7;' to the top of
> your script" - in the
> same way that 'use strict; use warnings' has been
> the mantra for the last 20
> years.

I think this angle of view of word "modern" isn't wise.

IMO "modern" means supporting modern programming techniques:
 - webasm (there was a thread about webperl ,but I don't see it in recent p=
erl)
 - multithreading (deprecated several years ago?)
 - llvm build (I want llvm@win32)
 - etc

The point "modern" =3D=3D=3D "use strict; use warnigns;" -- I don't buy it.=
=20
Yet warnings.pm is too bloated, to my taste (so I don't use it, but this=20
is another story)

I admit - the "use strict" feature is very good selling point of Perl.
But if the language does not support anything except "use strict" - then=20
it is hardly useful.


> People learning perl for the first time will know nothing other than to
> add 'use v7'. People working for big companies with coding standards
> will be
> told to put 'use v7' at the top of each script.

This seems unwise to me.

Are there any modern languages that require some version on the top=20
of the program?
Not in C++, Rust, Javascript - AFAIK
0
Vadim
6/26/2020 5:05:06 PM
On 26 Jun 2020, at 17:03, Dave Mitchell <davem@iabyn.com> wrote:
> On Fri, Jun 26, 2020 at 05:50:39PM +0200, demerphq wrote:
>> Ok, so just to be clear, my understanding that "use strict" and "no
>> strict" will be equivalent to "use perl-5-semantics; use strict;" and
>> "use perl-5-semantics; no strict;".
>=20
> I can't understand your obsession with just 'strict'.
>=20
> My understanding is that out-of-the-box, a perl7 binary will enable by
> default,  *a whole bunch of extra stuff*, not just 'strict'.
>=20
> So for example,  running a plain perl script using a perl7 interpreter =
is
> as if the following lines had been injected at the top of the script:
>=20
>    use warnings;
>    use strict;
>    use feature 'signatures';
>    no feature 'indirect';
>    ... etc ...
>=20
> is that the same as your understanding?


I thought the point was that if perl7 sees =E2=80=9Cuse strict=E2=80=9D =
but not =E2=80=9Cuse v7=E2=80=9D, it assumes =E2=80=9Cthis is perl5 =
code=E2=80=9D? Because =E2=80=9Cuse strict=E2=80=9D is a very, very =
common thing for perl5 code to say?

So if you say

 use v7;
 use CPAN::Module;

 my $input;
 { local $/ =3D undef; $input =3D <>; }
 my $thing =3D CPAN::Module->parse($input);

then you get Unicode strings etc. in *this* file; but because =
CPAN::Module says =E2=80=9Cuse strict=E2=80=9D somewhere, and not =E2=80=9C=
use v7=E2=80=9D, it=E2=80=99s still considered to be perl5 code, so =
doesn=E2=80=99t have warnings, unicode strings etc. turned on?

Sam
--=20
Website: http://www.illuminated.co.uk/
0
oldsam
6/26/2020 5:40:41 PM
--000000000000aa9dbf05a9008843
Content-Type: text/plain; charset="UTF-8"

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!)

--000000000000aa9dbf05a9008843
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon=
t-size:small"><br></div></div><br><div class=3D"gmail_quote"><div dir=3D"lt=
r" class=3D"gmail_attr">On Fri, Jun 26, 2020 at 9:04 AM Dave Mitchell &lt;<=
a href=3D"mailto:davem@iabyn.com">davem@iabyn.com</a>&gt; wrote:<br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">
My understanding was that, by default, perl7 will enable many of the<br>
optional features available via &#39;use feature X&#39; and/or &#39;use v5.=
32.0&#39;,<br>
plus possibly some other stuff.<br>
<br>
I think that this will break a *lot* of existing code and CPAN modules.<br>
Which is at the heart of my objection.<br></blockquote><div><br></div><div =
style=3D"font-size:small" class=3D"gmail_default">I am greatly concerned ab=
out this as well.</div><div style=3D"font-size:small" class=3D"gmail_defaul=
t"><br></div><div style=3D"font-size:small" class=3D"gmail_default">One thi=
ng 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.=C2=A0 As a cpan author and janitor, I would certainly appreciate b=
eing able to see which distributions within my control are affected by cert=
ain pragma or feature options, so that I can proactively move to make appro=
priate fixes.=C2=A0 There may also be some surprising findings from this ex=
ercise that would help inform us which pragmas and features should be enabl=
ed or not enabled.=C2=A0 Core and dual-life modules would also no doubt be =
affected, and they MUST all be fixed for whatever default feature set is de=
cided upon.<br></div><div style=3D"font-size:small" class=3D"gmail_default"=
><br></div><div style=3D"font-size:small" class=3D"gmail_default">This does=
n&#39;t tell us anything about the darkpan, of course, but it would at leas=
t give the growing list of keen-to-see-p7-happen volunteers something to se=
t their attention on in the short term. (I see the Pull Request Club is enj=
oying a revival thanks to the TPC too!)</div><div style=3D"font-size:small"=
 class=3D"gmail_default"><br></div><div style=3D"font-size:small" class=3D"=
gmail_default"><br></div></div></div>

--000000000000aa9dbf05a9008843--
0
perl
6/26/2020 6:03:45 PM
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.
>
0
doomvox
6/26/2020 6:07:12 PM
On Fri, 26 Jun 2020 at 18:03, Dave Mitchell <davem@iabyn.com> wrote:
>
> On Fri, Jun 26, 2020 at 05:50:39PM +0200, demerphq wrote:
> > Ok, so just to be clear, my understanding that "use strict" and "no
> > strict" will be equivalent to "use perl-5-semantics; use strict;" and
> > "use perl-5-semantics; no strict;".
>
> I can't understand your obsession with just 'strict'.

Dave its simple. I am under the impression that putting "use strict"
in your code is the same as putting "use perl-5-semantics" in your
code.

Meaning that all the things that get turned on that you are worried
about get TURNED OFF by the statement.

cheers,
Yves




-- 
perl -Mre=debug -e "/just|another|perl|hacker/"
0
demerphq
6/26/2020 6:15:36 PM
On Fri, 26 Jun 2020 at 18:03, Dave Mitchell <davem@iabyn.com> wrote:
> So for example,  running a plain perl script using a perl7 interpreter is
> as if the following lines had been injected at the top of the script:
>
>     use warnings;
>     use strict;
>     use feature 'signatures';
>     no feature 'indirect';
>     ... etc ...
>
> is that the same as your understanding?

Depends on your definition of "as if".

If it means "exactly the same as", then no, that isnt my expectation.

If it means "produces the same practical outcome for the developer" then yes.

Meaning that if my understanding of what "use strict;" will imply is
correct then we would probably not make the v7 semantics actually
trigger strict.pm, the latter would be used only in legacy code.

Anyway, i really hope Sawyer or Todd speak up here. Maybe i have got
the whole strict thing totally wrong. Shrug.

Yves



-- 
perl -Mre=debug -e "/just|another|perl|hacker/"
0
demerphq
6/26/2020 6:25:15 PM
--=-WANBVkvU+bSWSzKroe9t
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: quoted-printable

On Fri, 2020-06-26 at 14:46 +0100, Dave Mitchell wrote:
> On Fri, Jun 26, 2020 at 02:49:31PM +0200, demerphq wrote:
> > To achieve this change requiring new code to include "use v7" is a
> > non-starter.
>=20
> This is the bit I fundamentally don't understand. Convince me of this,
> and most of my objections will fizzle away.

To me, the primary purpose of not requiring an opt-in to the currently
recommended defaults is to avoid preserving the existing default
behaviors indefinitely going forwards.

I'd love to see Perl 8 fix long standing problems like threading and
Windows support. Maybe Perl 9 provides a transition to better designs
where both the old and new are supported, but why would the Perl
interpreter 20 or 30 years in the future continue to support the current
problematic behaviors?

The specific changes going into Perl 7 are less important than the idea
of the language evolving going forward from that point. If the set of
changes is too aggressive and disruptive for too little benefit it would
make sense to moderate them and make the transition to Perl 7 smoother.

It isn't reasonable to expect that all existing Perl code will be
rewritten for every major version change of the interpreter. It also
isn't reasonable to expect that all existing Perl code will continue
working without any modifications across all major version changes of
the interpreter.

Striking a reasonable balance between those two extremes while improving
the language should be the goal, right?

--=-WANBVkvU+bSWSzKroe9t
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEGNgF+IF46Km9DAl95E+AFtNjD4kFAl72RSMACgkQ5E+AFtNj
D4mxUA//cqmF5rp0JN4dSlhBcEqqxibu17oisiPOKKMGjbQiIkxcKDLNgkO87A0M
hzuCNM7VXxaphBHFtvv/v8scbeXPcPE1LNcru/1UZNsum1/9UeCpcqphKkPZ6sz1
drLGXZEOHhv9iyLzY6d/ueisRqrD/adOGNGt+g6m7uT8ux/GH41lfK+ufMSA7C2u
LbIEF7ityICN4ssyW80uTW8v4PtFyQm/PgoG44EG3zH/RF1CBqfUTm981RL79xzj
hUWUqcBdCSADIUHkb4DQnuC7VPNGtjnIpAVWDpiqV7o8MpnXVJp+/1zCflh7WK11
tMo3CMmscbWRFcE4bwabWahjgQKM/QWXuxvJ3jVvd5wGumdgILeSoCQK2Lpx2iiV
r2T/+XaXZefz454r27nyFs8KusnQaaHUiPIwTcaJlA77H5dwJbu1ggB0fzrpBIvS
ZvRwmgXQz2GhPj4hTG5tOZzCtUIn3ecsmuFpWdjyjn8l5WcCHYBQ9pyp2A5sBJCA
0EeCPDKlIvNRUEp/asVQNjQlQZ8Zx+ffuXikjZ+utvWj+6lsnrmPeogIUz248Awo
CprklkjvYu6hFVPwzYY9e6qnLrWs7R/ULZ8+rrqdhlZ8Uyi2TthkTzJ06NXhzqhM
QlkmzmKM9gxMCneLw7iz1llpINZqq2h6O/5CeD5ytN4Y74viBUo=
=IBWX
-----END PGP SIGNATURE-----

--=-WANBVkvU+bSWSzKroe9t--
0
john
6/26/2020 6:57:39 PM
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.
0
xsawyerx
6/26/2020 7:42:30 PM
On Fri, 26 Jun 2020 21:42:30 +0200, Sawyer X <xsawyerx@gmail.com> wrote:

> 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.

I don't have a particular position right now, but my brain's giving me this to wonder. When i try to think of risk scenarios, this one comes to mind:

A perl7 user might not be able to use, say, 50% of CPAN, meaning they can't *rely* on it at all, meaning the singular and overwhelmingly powerful feature of perl is gone.

If that is indeed a valid risk and not a brainfart on my part, then it could be mitigated as described below, and i wouldn't currently be left with any concerns floated up by my brain.

So, a possible mitigation:

Are you also proposing to empower and task modules@cpan.org to forcibly and with urgency update dists where this is not being done?

Personally i have absolutely no objection to this whatsover.

-- 
With regards,
Christian Walde
0
walde
6/26/2020 7:55:08 PM
On Fri, Jun 26, 2020 at 10:55 PM Christian Walde
<walde.christian@gmail.com> wrote:
>
> On Fri, 26 Jun 2020 21:42:30 +0200, Sawyer X <xsawyerx@gmail.com> wrote:
>
> > 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.
>
> I don't have a particular position right now, but my brain's giving me this to wonder. When i try to think of risk scenarios, this one comes to mind:
>
> A perl7 user might not be able to use, say, 50% of CPAN, meaning they can't *rely* on it at all, meaning the singular and overwhelmingly powerful feature of perl is gone.

What this tells me is that we didn't clarify enough how the module
compatibility that we will offer modules on CPAN will work. We have
indeed thought *a lot* about not breaking CPAN. It's difficult and we
won't cover 100% (nor should we) but we did come up with mitigating
factors which should suffice for a fair portion, giving users a
seamless experience.

We will work on sharing this soon in greater detail.

I apologize for not expanding enough on this since it does strike all
of us as an immediate major risk to this plan.
0
xsawyerx
6/26/2020 7:59:42 PM
On Fri, 26 Jun 2020 21:59:42 +0200, Sawyer X <xsawyerx@gmail.com> wrote:

> On Fri, Jun 26, 2020 at 10:55 PM Christian Walde
> <walde.christian@gmail.com> wrote:
>>
>> On Fri, 26 Jun 2020 21:42:30 +0200, Sawyer X <xsawyerx@gmail.com> wrote:
>>
>> > 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.
>>
>> I don't have a particular position right now, but my brain's giving me this to wonder. When i try to think of risk scenarios, this one comes to mind:
>>
>> A perl7 user might not be able to use, say, 50% of CPAN, meaning they can't *rely* on it at all, meaning the singular and overwhelmingly powerful feature of perl is gone.
>
> What this tells me is that we didn't clarify enough how the module
> compatibility that we will offer modules on CPAN will work. We have
> indeed thought *a lot* about not breaking CPAN. It's difficult and we
> won't cover 100% (nor should we) but we did come up with mitigating
> factors which should suffice for a fair portion, giving users a
> seamless experience.
>
> We will work on sharing this soon in greater detail.
>
> I apologize for not expanding enough on this since it does strike all
> of us as an immediate major risk to this plan.

Alright, i'm happy to wait and see.

I wanna note tho that right now it appears to me that anything below 99.865% CPAN dist coverage (i.e. the exceptions are a small, explicit, human-readable list with explanations that can be skimmed in under an hour) would be very dangerous.

Maybe i'm wrong, but i hope stating it like this gives you something solid to grapple with. :)

-- 
With regards,
Christian Walde
0
walde
6/26/2020 8:12:41 PM
On Fri, Jun 26, 2020 at 1:25 PM demerphq <demerphq@gmail.com> wrote:
>
> On Fri, 26 Jun 2020 at 18:03, Dave Mitchell <davem@iabyn.com> wrote:
> > So for example,  running a plain perl script using a perl7 interpreter is
> > as if the following lines had been injected at the top of the script:
> >
> >     use warnings;
> >     use strict;
> >     use feature 'signatures';
> >     no feature 'indirect';
> >     ... etc ...
> >
> > is that the same as your understanding?
>
> Depends on your definition of "as if".
>
> If it means "exactly the same as", then no, that isnt my expectation.
>
> If it means "produces the same practical outcome for the developer" then yes.
>
> Meaning that if my understanding of what "use strict;" will imply is
> correct then we would probably not make the v7 semantics actually
> trigger strict.pm, the latter would be used only in legacy code.

This is super confusing to me.  I think I hear you saying that 7.0.0
will have strictness enforced by default, albeit not via strict.pm.
OK.  But then you also said you have the impression that actually
putting "use strict;" at the top of your code will disable the v7
feature bundle and be equivalent to the backward compatibility pragma
but with strict.pm loaded.  Is that really what you are saying?  That
means everyone who has ever followed the advice to enable strictness
will have to remove the explicit "use strict;" from their code in
order to get all the new on-by-default features. That does not sound
like the principle of least surprise to me; the v7 semantics would be
invisible to well-maintained software that follows coding standards,
and a big, incompatible wallop to everything else.  Hopefully I'm just
missing a clue here somewhere and have not understood what is really
being proposed.
0
craig
6/26/2020 8:54:27 PM
"Konovalov, Vadim" <Vadim.Konovalov@dell.com> wrote:
> -----Original Message-----
> From: Dave Mitchell <davem@iabyn.com> 
> 
> > In my world, the big first public release of 7.0.0 will come along with lots of
> > explanations and docs all saying that "if you are writing modern perl, then the
> > first thing you need to do is add 'use v7;' to the top of
> > your script" - in the
> > same way that 'use strict; use warnings' has been
> > the mantra for the last 20
> > years.
> 
> I think this angle of view of word "modern" isn't wise.
> 
> IMO "modern" means supporting modern programming techniques:
>  - webasm (there was a thread about webperl ,but I don't see it in recent perl)
>  - multithreading (deprecated several years ago?)
>  - llvm build (I want llvm@win32)
>  - etc
> 
> The point "modern" === "use strict; use warnigns;" -- I don't buy it. 
> Yet warnings.pm is too bloated, to my taste (so I don't use it, but this 
> is another story)
> 
> I admit - the "use strict" feature is very good selling point of Perl.
> But if the language does not support anything except "use strict" - then 
> it is hardly useful.

I love "use strict" for projects I share publicly, too.  But for
personal stuff which uses "do /path/to/common.pl"?  Nope :>

> > People learning perl for the first time will know nothing other than to
> > add 'use v7'. People working for big companies with coding standards
> > will be
> > told to put 'use v7' at the top of each script.
> 
> This seems unwise to me.
> 
> Are there any modern languages that require some version on the top 
> of the program?
> Not in C++, Rust, Javascript - AFAIK

Most modern languages are compiled and shipped as binaries, so
breakages only affect active developers and packagers; not
ordinary users.

Scripting languages like Perl, Python, Ruby, Tcl have
significantly less room to evolve than compiled languages once
they've reached critical mass.

JavaScript is an exception.  For most users it's shipped with a
complex browser which requires constant updates, anyways.  I
can't say I know much about NodeJS, but I do hear about debacles
(e.g. "leftpad") and stay clear of it.

I've known many Ruby users and organizations abandon it due to
to the unending stream of incompatibilities.  I don't see Ruby
growing, either.

Perl is already a significant part of many Linux and BSD
systems.  It occupies unique space in the *nix world; so I think
treating it as a mature data format with version numbers is
appropriate.

I think Perl can and should appeal to newbies who want a mature,
well-tested toolchain with history and experience behind it.
That's how I sold Perl to one of my clients last year.
0
p5p
6/26/2020 9:56:49 PM
On Thu, Jun 25, 2020 at 11:58 PM Tom Ryder via perl5-porters
<perl5-porters@perl.org> wrote:
>
> On Wed, Jun 24, 2020 at 11:49:30PM +0300, Sawyer X wrote:
> >I apologize for not sharing this news earlier. We have been working on
> >this plan for a very long time. p5p is a public mailing list, and we
> >needed to manage the communication around this. Despite not being
> >public, many people worked on it.
>
> First-time poster here.
>
> I think not having discussed this in public risks setting a really bad
> precedent.  I had been taking a break from lurking on perl5-porters, so
> when the news was announced on perl.com, I assumed it had been being
> discussed on here and that I'd simply missed it, and was very surprised
> to find this announcement.  Can you please elaborate on "we needed to
> manage the communication around this"?
>
> 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.

There are many things in this thread that merit response (and in due
time I might), but this one does stick out for me.

Yes, it is unusual to say the least that this list itself had to learn
about this from a TPF press announcement. Clearly p5p is supposed to
be the place where all these matters are discussed, and I think it's
rather unfortunate that it was not used as such in this case.

And to be honest, it was a rather annoying process behind the scenes
as well. It was largely a spy game of figuring out who was in the know
and who not; and one of the main consequences of that was none of us
knew what most other people were thinking or especially why because
there wasn't any unified place that included everyone; this stifled
actual discussion.

All of that is particularly unfortunate because, as far as I
understand, it's the intention to act really soon. As Karl pointed out
blead is still closed, and I understand from the CiC grapevine(!) that
the plan is to have an RC in about 2 months, and until 7.0 nothing
else gets in. How come we have a schedule when we don't even have a
roadmap? When so many things are unknown? When 5.32 is entirely
unprepared to be the last perl5? (it doesn't even install a
/usr/bin/perl5, let alone other things that would facilitate
cohabitation) We are woefully ill-prepared for this at this stage (the
fact that much of my information could be wrong shows just how little
information is public at the moment).

I think it is not prudent to hurry this process. Currently we haven't
formed a consensus on anything because we haven't even had the chance
to do so. Opening up blead and committing to releasing a 5.34 just
like Karen already suggested would give us that breathing space.

And most importantly, it allows us to bring the discussion back to p5p
where it belongs; to take well-informed decisions and to experiment
with what is and is not possible without undue time pressure.

Because right now it feels like we're strapped to a rocket with 10
seconds to lift-off, and I didn't sign up for that.

Leon



Leon
0
fawaka
6/27/2020 12:14:28 AM
--Apple-Mail=_411A8762-A2D4-4F47-A28E-89F7C554B6CE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

On 26 Jun 2020, at 20:59, Sawyer X <xsawyerx@gmail.com> wrote:
[=E2=80=A6]
> We have
> indeed thought *a lot* about not breaking CPAN. It's difficult and we
> won't cover 100% (nor should we) but we did come up with mitigating
> factors which should suffice for a fair portion, giving users a
> seamless experience.
>=20
> We will work on sharing this soon in greater detail.
>=20
> I apologize for not expanding enough on this since it does strike all
> of us as an immediate major risk to this plan.


My apologies if any of this was mentioned in the keynote, which I still =
haven=E2=80=99t got around to watching; I don=E2=80=99t have a commute, =
and I really dislike watching videos of someone talking if I could =
instead read a transcript.

Nonetheless, I really do think that if you were going to announce Perl =
7, you should have prepared FAQs, Apocalypses, PEPs, whatever, so people =
didn=E2=80=99t have to guess at what this all meant. Saying to geeks =
zeroing in on their particular area of expertise =E2=80=9Cwait a while, =
we=E2=80=99re going to get something up about that soon=E2=80=9D is =
terrible timing.

To take a comment from elsethread:

> 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.

We don=E2=80=99t say =E2=80=9Cuse v=E2=80=9D in our codebase at work; we =
say =E2=80=9Cuse our::way=E2=80=9D and the private module our::way =
imports the various pragmata we like. We similarly have a perltidyrc and =
a perlcriticrc that match how we want to write code. These are never =
going to end up on the CPAN because, frankly, who=E2=80=99s interested?

When I write CPAN modules, I aim for maximum backcompat, and so I =
don=E2=80=99t use subroutine signatures - even if I really want to! - =
because on the off-chance that someone might find my code useful, I =
don=E2=80=99t want to say =E2=80=9Csorry, kid, your perl is too old=E2=80=9D=
.. I say use strict, use warnings, and frankly most of the time that=E2=80=99=
s good enough.

How does perl 7 reconcile these two demands: using the most recent Perl =
you know you have available to you, but supporting as many older Perls =
as you can?

Because as soon as I start writing Perl code with subroutine signatures =
for the CPAN, I either have to say =E2=80=9Csorry, guys, but your Perl =
is too old=E2=80=9D, or fork the code.

Sam
--=20
Website: http://www.illuminated.co.uk=20


--Apple-Mail=_411A8762-A2D4-4F47-A28E-89F7C554B6CE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;" class=3D"">On =
26 Jun 2020, at 20:59, Sawyer X &lt;<a href=3D"mailto:xsawyerx@gmail.com" =
class=3D"">xsawyerx@gmail.com</a>&gt; wrote:<div class=3D"">[=E2=80=A6]<br=
 class=3D""><div><blockquote type=3D"cite" class=3D""><div class=3D""><div=
 class=3D"">We have</div></div></blockquote><blockquote type=3D"cite" =
class=3D""><div class=3D""><div class=3D"">indeed thought *a lot* about =
not breaking CPAN. It's difficult and we<br class=3D"">won't cover 100% =
(nor should we) but we did come up with mitigating<br class=3D"">factors =
which should suffice for a fair portion, giving users a<br =
class=3D"">seamless experience.<br class=3D""><br class=3D"">We will =
work on sharing this soon in greater detail.<br class=3D""><br =
class=3D"">I apologize for not expanding enough on this since it does =
strike all<br class=3D"">of us as an immediate major risk to this =
plan.<br class=3D""></div></div></blockquote></div><div class=3D""><br =
class=3D""></div><div class=3D"">My apologies if any of this was =
mentioned in the keynote, which I still haven=E2=80=99t got around to =
watching; I don=E2=80=99t have a commute, and I really dislike watching =
videos of someone talking if I could instead read a =
transcript.</div><div class=3D""><br class=3D""></div><div =
class=3D"">Nonetheless, I really do think that if you were going to =
announce Perl 7, you should have prepared FAQs, Apocalypses, PEPs, =
whatever, so people didn=E2=80=99t have to guess at what this all meant. =
Saying to geeks zeroing in on their particular area of expertise =E2=80=9C=
wait a while, we=E2=80=99re going to get something up about that soon=E2=80=
=9D is terrible timing.</div><div class=3D""><br class=3D""></div><div =
class=3D"">To take a comment from elsethread:</div><div class=3D""><br =
class=3D""></div><div class=3D""></div><blockquote type=3D"cite" =
class=3D""><div class=3D""><span style=3D"font-family: Palatino-Roman;" =
class=3D"">1. People do not actually use "use v". This is what we've =
seen with it</span></div><span style=3D"font-family: Palatino-Roman;" =
class=3D"">so far. CPAN is an example, and every code-base I touched =
and</span><br style=3D"font-family: Palatino-Roman;" class=3D""><span =
style=3D"font-family: Palatino-Roman;" class=3D"">discussed with peers =
had rarely used it. It is true that this is</span><br =
style=3D"font-family: Palatino-Roman;" class=3D""><span =
style=3D"font-family: Palatino-Roman;" class=3D"">anecdotal because I =
haven't touched or discussed every code-base, but</span><br =
style=3D"font-family: Palatino-Roman;" class=3D""><span =
style=3D"font-family: Palatino-Roman;" class=3D"">I am in touch with a =
few major Perl shops. It is rarely used by any of</span><br =
style=3D"font-family: Palatino-Roman;" class=3D""><span =
style=3D"font-family: Palatino-Roman;" class=3D"">them. This has to =
account for a fair portion of active Perl code and</span><br =
style=3D"font-family: Palatino-Roman;" class=3D""><span =
style=3D"font-family: Palatino-Roman;" class=3D"">this anecdote does =
means something. We have a mechanism we believe is</span><br =
style=3D"font-family: Palatino-Roman;" class=3D""><span =
style=3D"font-family: Palatino-Roman;" class=3D"">superior and gives our =
users what we think we want. Our users don't</span><br =
style=3D"font-family: Palatino-Roman;" class=3D""><span =
style=3D"font-family: Palatino-Roman;" class=3D"">use it. Aergo, our =
mechanism isn't the gift to developers we thought</span><br =
style=3D"font-family: Palatino-Roman;" class=3D""><span =
style=3D"font-family: Palatino-Roman;" class=3D"">it =
is.</span></blockquote><div class=3D""><br class=3D""></div><div =
class=3D"">We don=E2=80=99t say =E2=80=9Cuse v=E2=80=9D in our codebase =
at work; we say =E2=80=9Cuse our::way=E2=80=9D and the private module =
our::way imports the various pragmata we like. We similarly have a =
perltidyrc and a perlcriticrc that match how we want to write code. =
These are never going to end up on the CPAN because, frankly, who=E2=80=99=
s interested?</div><div class=3D""><br class=3D""></div><div =
class=3D"">When I write CPAN modules, I aim for maximum backcompat, and =
so I don=E2=80=99t use subroutine signatures - even if I really want to! =
- because on the off-chance that someone might find my code useful, I =
don=E2=80=99t want to say =E2=80=9Csorry, kid, your perl is too old=E2=80=9D=
.. I say use strict, use warnings, and frankly most of the time that=E2=80=99=
s good enough.</div><div class=3D""><br class=3D""></div><div =
class=3D"">How does perl 7 reconcile these two demands: using the most =
recent Perl you know you have available to you, but supporting as many =
older Perls as you can?</div><div class=3D""><br class=3D""></div><div =
class=3D"">Because as soon as I start writing Perl code with subroutine =
signatures for the CPAN, I either have to say =E2=80=9Csorry, guys, but =
your Perl is too old=E2=80=9D, or fork the code.</div><div class=3D""><br =
class=3D""></div><div class=3D"">
<div dir=3D"auto" style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, =
0); letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none; word-wrap: =
break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" =
class=3D""><div>Sam</div><div>--&nbsp;</div><div>Website: <a =
href=3D"http://www.illuminated.co.uk" =
class=3D"">http://www.illuminated.co.uk</a>&nbsp;</div></div>

</div>

<br class=3D""></div></body></html>=

--Apple-Mail=_411A8762-A2D4-4F47-A28E-89F7C554B6CE--
0
sam
6/27/2020 12:16:25 AM
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
0
darren
6/27/2020 8:20:06 AM
On Fri, 26 Jun 2020 14:46:10 +0100
Dave Mitchell <davem@iabyn.com> wrote:

> On Fri, Jun 26, 2020 at 02:49:31PM +0200, demerphq wrote:
> > To achieve this change requiring new code to include "use v7" is a
> > non-starter.  
> 
> This is the bit I fundamentally don't understand. Convince me of this,
> and most of my objections will fizzle away.
> 
> In my world, the big first public release of 7.0.0 will come along
> with lots of explanations and docs all saying that "if you are
> writing modern perl, then the first thing you need to do is add 'use
> v7;' to the top of your script" - in the same way that 'use strict;
> use warnings' has been the mantra for the last 20 years.
> 
> People learning perl for the first time will know nothing other than
> to add 'use v7'. People working for big companies with coding
> standards will be told to put 'use v7' at the top of each script.

Plus a "use v7" at the top of a file will be a BIG HINT to things like
Github syntax highlighting, vim/emacs/other editors and IDEs ... so
many places, that they should pick syntax highlighting relevant to Perl
7, not Perl 5.

Alright right now I am in quite a mixed place, trying to have vim
support both signatures and pre-signature prototype notations. It would
be alot easier if vim had a standard signal to look for, to tell it
*which* set of two different kinds of syntax rules to apply to *.pm
files.

  use v7;

would be a very easy signal to look for.

I can imagine the github/et.al. highlighters would also appreciate such
a useful signal.


Alternatively, if you are really fundamentally strongly suggesting not
to bother with a "use v7" them please explain to vim, emacs, github,
and all those other places, how they are supposed to syntax highlight a
*.pm file.

-- 
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk      |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/
0
leonerd
6/27/2020 11:18:30 AM
On Sat, Jun 27, 2020 at 3:15 AM Leon Timmermans <fawaka@gmail.com> wrote:
>
> On Thu, Jun 25, 2020 at 11:58 PM Tom Ryder via perl5-porters
> <perl5-porters@perl.org> wrote:
> >
> > On Wed, Jun 24, 2020 at 11:49:30PM +0300, Sawyer X wrote:
> > >I apologize for not sharing this news earlier. We have been working on
> > >this plan for a very long time. p5p is a public mailing list, and we
> > >needed to manage the communication around this. Despite not being
> > >public, many people worked on it.
> >
> > First-time poster here.
> >
> > I think not having discussed this in public risks setting a really bad
> > precedent.  I had been taking a break from lurking on perl5-porters, so
> > when the news was announced on perl.com, I assumed it had been being
> > discussed on here and that I'd simply missed it, and was very surprised
> > to find this announcement.  Can you please elaborate on "we needed to
> > manage the communication around this"?
> >
> > 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.
>
> There are many things in this thread that merit response (and in due
> time I might), but this one does stick out for me.
>
> Yes, it is unusual to say the least that this list itself had to learn
> about this from a TPF press announcement. Clearly p5p is supposed to
> be the place where all these matters are discussed, and I think it's
> rather unfortunate that it was not used as such in this case.

We (and this "we" includes you, Leon) know for a very long time now
that p5p, the mailing list, is not a very practical place to discuss
major changes. It is the primary reason we held summits in person -
all of which you attended. We had discussed numerous topics and
vocalized our agreement that it would have taken far longer (and
possibly not had been resolved) if we had done it on the list, such as
the decision of dates and versions for the elimination of all
deprecated syntax. The last summit (near end of 2019) is when we first
raised these ideas, by the way. Discussions of which you also attended
in person.

The list is a good place to bikeshed, get ideas, and suggest some
topics, but it is rarely a practical arena to make large-scale
decisions. I'm quite surprised that you expressed surprise at this
since you attend the summits and know this for longer than I have.



> And to be honest, it was a rather annoying process behind the scenes
> as well. It was largely a spy game of figuring out who was in the know
> and who not; and one of the main consequences of that was none of us
> knew what most other people were thinking or especially why because
> there wasn't any unified place that included everyone; this stifled
> actual discussion.

This is incorrect, Leon. Everyone that was involved with this was in a
shared file and viewable by everyone else. It was clear who was
involved. We also had discussion threads that I initiated and tried to
keep going. The "to" list was open, as you well know. Furthermore, we
held multiple meetings in which we discussed it. It was not the cloak
and dagger that you're describing here. I recall one meeting with you
that took place until 2 or 3 am.



> All of that is particularly unfortunate because, as far as I
> understand, it's the intention to act really soon. As Karl pointed out
> blead is still closed, and I understand from the CiC grapevine(!) that
> the plan is to have an RC in about 2 months,

I don't know about this 2 months period.


> and until 7.0 nothing
> else gets in. How come we have a schedule when we don't even have a
> roadmap?

This is when your arguments also create a contradiction. On one hand,
you say that this was done in secret, that it was thrown on the list.
On the other hand, when we left a lot of things for us to openly
discuss, you express concern that these items have not been resolved
yet. We can't have it both ways.



> When so many things are unknown? When 5.32 is entirely
> unprepared to be the last perl5? (it doesn't even install a
> /usr/bin/perl5,

/usr/bin/perl5 is not what we determine. It is what the distribution
determines. We raised this several times as well, in those discussions
too, as well as in my Q&A on the second day of the conference.



> let alone other things that would facilitate
> cohabitation)

We have discussed these as well, Leon. At length. I accept feedback
that it was not shared well. I wholly disagree that it was not
discussed or is unknown.



> We are woefully ill-prepared for this at this stage (the
> fact that much of my information could be wrong shows just how little
> information is public at the moment).

I disagree. I think it is difficult to unfold such large plans (which
we clearly still have to do), but much of it is left open to figuring
out together.




> I think it is not prudent to hurry this process. Currently we haven't
> formed a consensus on anything because we haven't even had the chance
> to do so.

This is also incorrect. We have been working on this for over half a
year. We had numerous conversations on it with a staggering amount of
stakeholders. The picture you paint is incorrect and in that regard,
also unfair.



> Opening up blead and committing to releasing a 5.34 just
> like Karen already suggested would give us that breathing space.

Perhaps. This is worth discussing once the dust settles from
statements that characterize that almost no one was informed, that you
had no room to comment, that it was forced upon you, or that it was
both done in secret but also not fully done in secret.

This shows an example of the problem we have with the list. The public
feuding on the process not being exactly what you want is mixed with
the need to pin down the rest of the details and potential ways to
move forward. Having to respond to the former also takes a lot of time
from being able to focus on the latter.


> And most importantly, it allows us to bring the discussion back to p5p
> where it belongs; to take well-informed decisions and to experiment
> with what is and is not possible without undue time pressure.

This is again, ignoring the reality that p5p is not best suited for
*all* discussions, only to some. We know this and it is with this
practice that we ran for at least several years now in which we've had
core summits.

Now that we resolved to make this decision, the discussion is brought
back to the public. But at the same time, you cannot complain that
these details were not resolved privately.



> Because right now it feels like we're strapped to a rocket with 10
> seconds to lift-off, and I didn't sign up for that.

Again, this is an incorrect representation, because we (including you
and I) have been discussing it for a while now. Your participation in
it was limited - by your own choice - and now you come back with "this
is all so sudden to me." It isn't.
0
xsawyerx
6/27/2020 3:20:38 PM
--MP_/570Ji7JA+YU_G6PSClioNnl
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Sat, 27 Jun 2020 12:18:30 +0100
"Paul \"LeoNerd\" Evans" <leonerd@leonerd.org.uk> wrote:

> Plus a "use v7" at the top of a file will be a BIG HINT to things like
> Github syntax highlighting, vim/emacs/other editors and IDEs ... so
> many places, that they should pick syntax highlighting relevant to
> Perl 7, not Perl 5.
> 
> Alright right now I am in quite a mixed place, trying to have vim
> support both signatures and pre-signature prototype notations. It
> would be alot easier if vim had a standard signal to look for, to
> tell it *which* set of two different kinds of syntax rules to apply
> to *.pm files.
> 
>   use v7;
> 
> would be a very easy signal to look for.
> 
> I can imagine the github/et.al. highlighters would also appreciate
> such a useful signal.

In fact, there is already precedent for this. Right now, vim uses the
presence of the word "bash" on the shebang line of a .sh file to work
out if we're expecting to run the script in bash, or just any POSIX
shell. Based on that, its highlight rules can show you big red error
markers where you are using bash'isms in a plain /bin/sh script. See
attached images.

I would love to have similar for Perl scripts, to highlight big red
error markers if I try to write syntax that isn't valid in v7 any more.

  use v7;

would allow that and give vim/emacs/other IDE users some lovely
highlighting to guide them into writing the proper syntax, which they
wouldn't be able to do without it.

-- 
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk      |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/

--MP_/570Ji7JA+YU_G6PSClioNnl
Content-Type: image/png
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=vim-sh.png

iVBORw0KGgoAAAANSUhEUgAAAI8AAAA4CAIAAABLzjwJAAATm3pUWHRSYXcgcHJvZmlsZSB0eXBl
IGV4aWYAAHja1ZpZkly5DUX/uQovgTPB5QAcIrwDL98HL7OqVZK6LXXYH1aFlNU5vEcCF3dgdjj/
+ucN/+BPnamH2ob02XvkT511ZuUXia8/8/k3xfr8+/yR+34tfX0+lI8PZZ4qPJbXfw59v195vn1z
oY/r2Nfng7xfyfK+UPq88POn+J399/3tInk+v55P9X2heV6/9Cnj26Xa+0Lr/cZnKe+/9XNZrwf/
7/DliUGVduNGJedTUonPv/JaQXn9Vf52/s1l8L5UBr+XMsLz1MeWKMiX7X08xvhtgb4U+eO38H31
e/158bO+31G+q2V/14hffvpCat89Xz7vn7+9cflcUf76wj0p/bCd9997t9x7XrvT2qlofyPqKXb6
uAxvNEpeno91fgZ/G7+P52fyI1HjouU7rmj8rDRTpis3pJp20nTTeR5XWiyx5pPpSc555fI8J/Ro
5lW8T9V/0s2jzLKL0KyVT6B1teTPtaTnvvO530rCnXfirTlxscRH/vQn/NWLv/MT7l1eouTFpPXp
1eDsuGYZ3jn/l3fRkHTffWtPgT9+3u2P3wALqNLB9pRZ2KBGe13CWvoDW+Xpc+F9jccX7lIY+30B
SsS9G4tJhQ7EnkpLPcWR80iJOgoNUlaeS81GB1JrebPIXEvpOYws2e/NZ0Z63ptb7tmfhptoRGOy
Br2ZRWlWrQ38jCpgSFtptbXW22gS2mzaS6+99d5Hd5LTUUYdbfQxhow5VIpUadJliMgUnXkWOLDN
PseUOadqDsqNlGsp71eesWzFqjXrNkxsmi7gs+pqq6+xZM2lO++yoYnd99iy59aTwoEpTj3t9DOO
nHn0grVbbr3t9juu3Hn1s2vvrv7w8xtdS++u5adT/r7x2TWeDWN8XCI5nTTvGR3LNdHx4R0A0Nl7
FiXVmr1z3rM4obHSMots3puwk3eMFtaTcrvps3d/dO6X+haa/FLf8n/qXPDW/Tc6F2jdj337Sde2
69x6OvaaQq9pLEzfzbajhVrktnYtbVvoEbvjdnpOX4fZHWnmYfF06/naSnkr91/sBsz31VO1OfO2
rGGxlk2nR1ojF9EzIduiXeKld2WzlLat7ZX6uSUvigMarDllxnEHq9mjlhPy3nUsungFlbboNEjj
d5nXOmy5lo64YUNKdZte5b+LtJOoT7YjPJPPGhoSi9+Zem/TdPrUfKWUa6PuNfbsyQbXrXVnNtFE
BdpdMxY5RrvvntbHvW4izpntiJ00e7MIvro15Z3WpB7DfbRVoHCTZcnyBOO2xZu2x6iWof46+HC4
z3Va1gGQytwnKiSTvS5lyOp5L+rWZjztRhzQhkd3d3hzGcAHnNsWGWEAit7qGKkNcLCSKSu7kukF
sInjbCZhTylLwZDZ6OfEseljWcADXeJ1O0Fgt32PTKRO9gIDc5pkG+XwUGkjm8u7n31pyeH2LHl3
EAlEjnI96cd6C4vVU0pdU9YpG2K1qUz1KbGDclvzbJbI5SkPEzhBwY1lTRoCkhDesXfWG2TDwQg1
yyz1zgluCs1LYH3dWXr3aaXge7R9ypQMauZNzOpgFPsGtGvNnAKjHjtgUVfZlqjKHenc1tlkGTOx
DUlazUAqo82WIZY1Rh5noanCh5j2W8MdCrLwSrf3DSv4MCO8GK2d5mAkQOIZ6QMwjpY6/L3T0bOu
aRvKpwJwdG7AYgjIm7o6VcyH9y+ruTcBhcPXHpF66q06hKptL/Nm6fyaIVALYrCGaOdlCFLmLZ1S
MEbmdwReyWdOJ0VfENfZjS0pnrAOWpv9eQF8uBE94FObVaZSLOXZ2VvPrTHHQGzsCqzLq0cL7ZY7
qt6a7BS/VRRABxkHi+3O7k8hsk1hgHNrT155blqXgvCyIlXosF27Vdl7ZhtXTqb6G8ulabYA+lav
6RQFEJnFM5e8BL5tti5W24VtTSFWhtT33ydBoZ7YvM58MqNS/XAhaACJq/WotsN0WKsmTFG6g/ou
BpT5PG3qHa3vwrz6+uuwsVm9QYC6rIebIG38xTLuliCTO/dANRqXtdVOvpARdgdmZPYOBq4bzynG
57SKg7gLfMwd6BnMOik5zpIH3bpLh8BrnQtG0AxpLwAqYByuYunCfHdUBXh3U7mC5q2Q+mWsbAGO
XTHThaawApDrUzf0TjgA0bO1V6NKC0zqtrk3EsVd9HTMpmjgryca/a3H2/eNbAqjRMlo6qVGsIii
dGnttFQevR8Id0/rsojjzpV1FZRm+djqrsYFKC+k3BhC/BbhZAZGgOaMctFWpE8WDHd47VgaOAW0
Ho/cG+WAGrn4LfpwNAS1/ZEK3GuHob1OaEAImk9zshg6XdpBJHODnc9RnpMK9SjTgDmjoQ8AFiTa
0VAGAtEKmrH3vWPFGYgLmMFNvVEAQpftMO5mueK2zWRXEFoh19FvggQLcgd93DxvYIVm9xwQ7Atd
sENSlyNnQptp3I3HvwsmmhAeLMcGy5zQChSHt6aihy0E7lcU+A7fUKkTZp8QS0cUEz1ngpnQbNDF
JXc49TpakWyW33EPjtuKLQtYFb+OMeiV7VJJCDil+8srpRSTPBuYT6gaW+MIa6yS39RwLA0p3Akz
w7A7XBD2WsYepYscoB3F5Qe4aKqw2dO1XmGJC8VddO1CHLKtwktq+9hem7mHYbDoCVOi/FIKsk2p
fe/3tcrwdZlfdvTsx4MuBgW0gis8n7bckMnMzzg1g/Hqowqya9kO0Q0E8FdVdvTJwvOVuKVUQwZb
lRVxrdvpUV3mJvK70HxwkTfzvmtgT3RM3GTR3rEUp4jex4T83kjdz89X+VF3zNKzpfDeE0raeQph
AAV2K4wlhcZz//qMAtiB3wS57bzDOWtADt1vefN28kcb3QiyX8P85n7xVpuGJLzkwCzjUdROc9km
oS5Po3IhE/jFMXZfQzdCfuaGqUMf8DNsYrDQhTYcFBuualoWORVhRT8xCeyoNgrkQ0n19jwgmhFh
sZVPA9xqF3YgkYP8Do9nCHriMNSZdCjE49UdBhWKGLpOPMO5Y/FxBDVgvysUzwwaDOEV+/Xpo1bS
8b541ROQXAwCrsYRMdDyhIGiHmyZ9TOpA7VFIcFFjtfTRkdFESumahgOFbzCnD1AyKelhsddaD4K
rWgbBNR5AySNerBFxLPyJkjeH2uLPz6GP3vhdx//lxcaw050lYBniTkYXCZXmV26xhAYdgYmJ62j
o07y5AMwFzAiF/uG/ayPkREAkm7CGsN8XFCsuAc4B17EH8AUE7NeKNtImDpGuBVMl6cjNBnwqHOM
mzNME+Z1YqoPCMr08fEq3Wn2+lEJMESdro8AoovQX8xED21gk4QnrzjT4oJY4LLBnDNPTkDEJlE/
OXASYuboYwR2Spo7EaTAtiQ9UjZxcB84gtSEzncUca58bnfu1VMSKi2yVvPsB74TOG/+YPh/wQBC
j7YsJEbVuQUep3ANfw3LFrIcwW9R8Y6UQcmYzj0uTGrmebleJArecZNArmR/ISYsNqODCSdplDqY
3OqApagbzYGseRZe9dOwxwEtvFk/i8WT725ncZjxGuCgy9YumcgQaniclERQwMF4aCBAitM+2VGY
soJGUWOSKY6tNagZOLD53QLchGdNipfE429Pb25MGY65DnswiiGR3ALfNROEUVLGCIzuKaVmt02j
ov0mXusyj6v6xSmpFMM9SMK6Qb0d3rktdsgjstiz1I9N/dQKu+zpBdbD1VpYZANIpNSGQcQ96mBo
YQuADHVC7Jjq4yWE4tEDUmTmrZVowVXI4vAGsUerK+3MvlcQkEioEYJw71ZA5oZaD9fCP+OrF97R
MYQynwkpFcLQ5GJkGsJUAKVEI6mPNmBn1kEH6kn46oRXZ2Jq2/tgfDqcNTohEW2eBqmiURSRIhWu
HmgNmb8ZcX8cPD0y1QuJuVY6xEQipdtzBAVbnvWwIJFw6/SJ7ZheVhAjKaS7wGj2QXSxI1xn5orG
3cJQ0/3NNE6PMqll5nVfxhZTiLB2phnBJZ7jxkP1DJY8+WQnc0IxI4aFZH3NcxgjjXFRnwoi/2Ha
JVYmGSUmMSEHEAtRuTK0xAXsNLASJ/cGn/TEuK50GG3GApXDMdEvsnNlloDWdevQYSVQw7DtsnFs
uBc8iDbBDXJn5ItuonqA4Fn/8iMiP6rxSNVQqEwKQiE8KC/KB7W4rOJGAHshVVDfljPkRZM2mEPk
aEPMTzTflPeSX9uuj3n3UWwpoUDeRvxgD3t5zsx64KPT4yEILG7ZQFnbZDa2MIhgCBX73w5aekcH
Gubm0n4/TOpua06xx1PQXSaArsalvomUfGWViW1xJqwO9IHuw7ll4CDdJWe3HITbxK1KwGEoiIDP
42E4uO11j1EVXkdV2QpNdopt6IGlujH2TC9hIRIMiPw4J6xbCZ3Jvp7Wi2dtLgPjqEn10/BCNFdc
FBbTvLvkrJtwBsISsH73OV8jiSPgI7TOqF83ZdwR1ZkMnCdOVLxABEkYPpDFzHnQpxAUp7NtZjgh
BlQX4VhlM2uPNeI54nwGvYQoxumiIQ7HjCVfyFt2ht8LXTlX7/JzMwNnuAPyox9TBNwTGRdihkth
A0yEYpDI9yARujzUBJ8WT4pul9BO/FB7LBHvEsEnPK0aYfnkkCGjB/HosnS5vtwnt5KKhlX/DEkk
SVmZRFAdIVDcxua8LgN/5+BJvuHEQQzamv3kvr1Qi8m+sIjyUXzKziQXP2akCL37PMFuB3fuyQqm
Dn7otBJzMt0NE6/Q3wztLPr7oG34uDU0/eCusWKCPR0e3A9CWqFF5zPdAaQMLCRERqCGBbAJxITc
gH+7hpHFV50E4CvpAqrl5s51hbGciDnelrAWtQSvIs6gEMRvkj1xygRKZDVaMWwZBdXIsALQjQu+
zyEkK8AXk2Fv7kgMuTWhaw0cDeb/gl2ugo1mUEj3hDxBtZkTjN/yszCbcirbR8r1VeTGjN7D/UbA
gdJR/27nJBDp3nTgESwPdPn4qRW9yP1gYvws5rGAFL2fD0dFW/1ANKBEdKplJhG+Vj9ZYZgBIxtJ
Pq3ZYmSwneXApLgA0yC6mjSStSk/VewNw47kqatkp0l4UOwCj346WSnrmOaHWegzzLELdo7QxSww
LePpAwpTkqEieHDS3oUT9YnClVBWYYs+oC72i40u2gcRRfzMRyEhgTvML8W6IGyYOqccsjAEZRJo
csInLGLUkL0R/Wt+8BvxgDD3GNqnH5TfKX5ECXUoikNTe3aLpsEzB74eb3moRturUGZMDHOB+S74
NaLCIV3yBh+sWnzJhEzl3jAAggj/yAjFzzHLsog3zDQ+g1MPov4sSELGDoySEOCxHRTEPTTisa0q
L1AKlieGhl5SIKBcCppWkztX0Ywmx+seK/txEJ+u1WMl0Pezb3hiZsrHJ5bEzQJDWf35cpg7G2ri
PcPpTD/Uoor8UoBU9CBV/YSFcqLaRFnLE3BgxJy8kDAy7XED1aQR3yWV6X71TD690HQIGNmeh9F0
0nYP3/xsB9OOGcA8+tFtZQoGHlIr5b/shDKfOzAHioFhwpObQbZYCPkMgZszPwIm69SEZ2IxpvAJ
assQh40akDPrIjHP6QePPnrAlZKtTdJGMaMPiZ+j+mEmg8d88VbomqZSDprKiCwIx2O3O1pcKOOD
prZDMzuYAdAelnfpBXj5ITOOGbHZDBaL4y6MElOwUBFmEM6CaTDxrtoeao9bOBQKvolo0cQmYjpG
EmJr8YzB+EL6pzONw0+UMezTqZMZjeZsrSCWTyISm+vWJ8mkU9XJcpzeTZaSGVBERgBjS/cGCmMl
h4pwEG5ve4wlnqskSsPytU0XOPNM0wpMwchG3ZGeHRLXuWcSPgVjRjObBfNzds9T8COJBYEbblma
YsySBzUohYDT/FCvuXJgQDHa8M6ZE/B6lCLnzvAcdpOBX4laHxlKrbq0Lb+bn+l3N6xU3l8j98Ig
ONHtTpE5xxcRzGNAQXBvCOlkTI8bLgp8Gf7qhyyAX3GlnrK3R0OkGMbCc5f4lBayIpyxqxsqWoqc
PIcFdBTv3CZwbRRUl+cynwuhEX++Qnm+8nHD/tZLDzfP6YB/g9k8f5aGoKpMrBsOJZ4mfiSpfuR/
EWG3O8zoYyQDxhsFnH6O7l9UFoVKGIozugtVc/NMS5n42RVDv9cd0Y9rzvIz0LsGJuNGzyII+6vu
f6PswkU9topOoihFrRPeRJ62zykpN+NqDgOHqfVv6riTkaXIrN3HXXFWBEc6hk2AAP31iqs1/xLN
T7v8TCwhP1gNZgDkiZ8LTwy3XdfF4idSRpCihhNNWq8Do/b6fo0AXf7YGxL22t2zN+iOvcEXeH9Q
aMetDXHEgwMRwa3k66yAwQpQV98RR2QL5+OumGga25O+tGD4bJhbZXSYAKGuQh5Coh6YKXtax0cS
A4MTStf1l0ier0Psk4FuMaj4+YqjpWVyiWTka2rkLWaKMYcJr9f8/9zARlL5AvHhryDYYeoRAjWp
Wf2rUjzc42xgqmyDYNMHfATgO9EaX+PzrA2HRRMhV/9eBfHJyHY7Xgwykz018a8YHGBgGjoVgzdX
AHsIGMYfvNLk52vQzk8TydO/VE1zPF+DoiOYGOjD09ykNMRE4gw2geBFsVkLmQNLyqQkEU9BMHSF
FqEK6HBjBaGq5/9Hgr+if3tA/5B1+fKVQvgb30H89PH/80KM757h3xKlXEEAH0drAAABhWlDQ1BJ
Q0MgcHJvZmlsZQAAeJx9kT1Iw0AcxV9btSItCnYQdcjQOlkQFXHUKhShQqgVWnUwufRDaNKQpLg4
Cq4FBz8Wqw4uzro6uAqC4AeIk6OToouU+L+k0CLGg+N+vLv3uHsH+OtlppodY4CqWUY6mRCyuRUh
+IouDKEPMYQlZuqzopiC5/i6h4+vd3Ge5X3uzxFW8iYDfALxDNMNi3ideGrT0jnvE0dYSVKIz4lH
Dbog8SPXZZffOBcd9vPMiJFJzxFHiIViG8ttzEqGSjxJHFVUjfL9WZcVzluc1XKVNe/JXxjKa8tL
XKc5jCQWsAgRAmRUsYEyLMRp1Ugxkab9hId/0PGL5JLJtQFGjnlUoEJy/OB/8LtbszAx7iaFEkDn
i21/xIDgLtCo2fb3sW03ToDAM3CltfyVOjD9SXqtpUWPgN5t4OK6pcl7wOUOMPCkS4bkSAGa/kIB
eD+jb8oB/bdAz6rbW3Mfpw9AhrpK3QAHh8BIkbLXPN7d3d7bv2ea/f0AYdJyoDXwHOIAAAAGYktH
RAAAAAAAAPlDu38AAAAJcEhZcwAACxMAAAsTAQCanBgAAAAHdElNRQfkBhsQJRc+XyBaAAAKk0lE
QVR42u2be3BTVR7Hv0mTNEnTJqXPNI++nzRJ29CWR9lCUWEUGJRxQRihyNBllGFmfY2IwnQRRVdE
VGYtuPJY13UcdYuO2yJIu8gKLbShD8CWQGuTpo9Aad6PJrn7x02TtKR1V+so9n4mf+Sek985557v
/f1+557cC1DcPdAAVODi3XsCBzFr+qhFnxrN6Xjbkj9Dygpa+5I6N7k4bKpGvLMtJ2tR+PT0Lb9a
YTMYu67lAnjii7SUOf7JTZkT9pY5n3aHrMIc9p/75CwuHUBMaihB4LbGGbSPF9Lauxos/8toAtsM
SgiTFpfJ7r9qn+5qJRVyv79oASDN52ou2XzlkjyutsVKeMZbLt2Z8NXrA06rB4BIxun/zk4QP3U0
gW0GJT6LPWLzDOtGprtaUiW3+4I1UsIy33KN2DyBamlUtjudION3vH//RU8eiuVcyy3XH09lvG3J
f7w6lcGiAaCH0A44CqoI5TPfZPoM81YItjVmrdovecuc//zFbF40Y6I2Adz7VNzLXbL9xrz1h5NI
hxPJOAOdjqDm00WtpKKwKkK5Yrfo4b3iPT0ysZxTRSjz/uAYVYvT02yd3AlEco4kn/vps9rtqe2S
fK7y95EAPG7iidDmz3fotC1+scVyTkxKqOqfw8+JW5lsmnwZf6I2s++JWPB4zP7F155NaB3qcQpz
2KR5dDIrqPl0gAGgu9GyOaTpVa38+eS2la+Je5qt547eAkJ9wefGOfOdjnV0Q7evRCTjHH+hlxRV
o7LyhcxA17xca/CrpeDWvaPvrDcBMA64nBbPRG3yhUzLkNvQP+Iwe77YqfN1FNR8ekVCsZw70GF3
OYiM0nByLkjCYxkjDqJvbFYf5wQsLj0mJbTluFcSgZh1s8sZoBYnMAuKFZwrJ42+qe9ts02UsS5+
PHTlpPGZbzK31qb7lpQiWXDzaaTWXr3iBVV2xoLwKkIpVnBe7pbN3xRNVpsGXU/HtkySsQAk5HII
D2EcGAEQKWYJs9nXznj1ZoeHzJCyetu9cxrKo0clsXpbbQAECUw2jz7Q6QjaJgCXg6h+vneX4srV
k8ZV+yUAOPwQgSiI+fSKhE/FtDx+PPXUG4PcyJC8FYIj5f5wtO69xBE78Y8tPZMs28RyDp1Bm7kk
Qttie/RQ4rdHbpkGXT5PGlQ7fGsWsZx7s8tpN7nJkNjbbvO4iaBtJheHFa2Z8dXrAyM2T+Isrq7d
RjqT/objTvPp5VtMDl2az1WfNcuX8Vs+Hw6sjk1nD3TaJ3EschLPVOlXvSn5U8dM/Q3HJ09pATz8
hphcDcZnsasI5fambFI87SWrT0hy9RG0TW2rzeMmXlRl72zPcZg9Hz+pJTu605zaeZqQTR+ldF+w
nNw7MIUj+IltTqudJ2qfcPrtE1JQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUNzN0H4FYyCmfGDEggW/
5JzW1wUZEgGBQGAwGH5Ky//3/1suV2ltrfznOMnIVMjWQLHut+AEaYuhWIcE5RQ3+8v8Gykq2hPC
EowrjM9Dnwqtf/P+IPW+an+V4tmMpd4LNly0SFlBxOdtIw/ZgixlBaGsIPI32rIfao4QL56w14oK
vPSS/3D1auzb5/1eUIC6Oqxd66/duxerVo0dtAh1deBwvIeHD+PeewHg2DHU1fk/ZWUA1Cdw7V8Q
KkELuZvVYguyM5efiZM/mbXiXGTyysAqBhvWmyAfpjdqasITSjH6rkS4qMyoqSG/C6RLrbcuCRKX
Bdqq/sppOTpjSP1B6n2f3nkdeGlogEIBOt2vUEOD9/ucOVCrMWfOjzyrXbuwcKH3c/o0WWa9CcIN
BvtnUGvmzLC6ujyjcX5nZ/HGjULv9DFolZVJXV2z9fp5b76ZxmR6c0lcHOvs2XyTaf6RI1lkSU5O
WH19nsk0v62t8IEHoibpT1pywKSrH2x/u6vuUf7YGafR/CnMPPAfgM6NLgBAozN58SWGUbX40gf6
miq5MUoGOybQ3OOy6a+8S2eEsfnpwftubwedjvR08twgk6Gx0Vs1ezaOHkVmJgSCqUzIBGi0qVaL
yw05cULOYtGSks4fPKh7773MhQsFALZtk+7YkfTqqz1JSecvX7bIZDzSJjmZvWbN1U8+0a9fHy+X
89hsek2NjMOhp6Sc//ZbQ3V1bmYmd6L+GJxYo6aW8Iw4DOru+nJfeVgMGGw4R98bIjwuU++piIQy
AGGxxW7HsG2oDQCbn8HkSYyaWuvNS3zp/WPEDgmNyljvcgzZDR1jYldZmffQ7UZTE/LzASA7G2Yz
btwAALEYsbFobIRajeLiKZxcpxl8CWj0KVXrnnsiRaLQQ4f6hoZGqqp0AFavjgWwYYNQrba9+67O
YnEfOtTX3Ox9Are52dzTY1epzACEQlZpqUAqZb//fr9eP/LOO70MBm3t2riJ+htoeU1ScoAXXxIW
W0gbDeppS5D1IAbb4Qp4QtCgqQlPWEgmKr9jJS6zDJzzuO0m3Wm+dKnvx/kbbQUb7XHypzuOz3U7
jROebkODV63AMDh3Li5fhtOJ5uYfGQxffNGft5KTfcW6C5DMm8p1Ex2AWBwK4PDhLIJYYDTOB5CY
yCbLNZogjy47nR4AHg9Bhi/SfHDQCaC/3+lrMCi3Oo9dP7HcZddHZZRnPXiBwY4mc7K6FrGyMVHe
qKnlxZfQ6MyIhLKAMLjUpDsNwKQ7HSFZTKMzA/JWlNPcHZ250d9Eb29gIgGAxkbIZGAwxictlQoA
VCoUFoIxwVtGHs+EJYF5q6vLV59QiL5mtBybMrUYAHQ6B4BHHrny0UeDgXVarWOSeQ+YEweA2FgW
mdJIw0njg8Y+3NF/aY+05EBU5oaBFoCAoQceJ1g8uEafDHZatA5TV7iwlBujNPWeAhDC4vPi54Un
LEiYtcu7+hCWOi1a762FY6jn7Jbsh5oG2vZN2Ldej74+KBTIyEBTEwCEhSE3F3l5eOwx728UCm/V
OOx2AP5FCoMB2w88LMzi4fZ1EJ4p9a2vv77d1+fculUskYTGxDA3bIgvL48HcORIf3o6p6Iigc9n
bNokLCgI/rZvff2wRuMoL4+PjmZu2SJyuYgPP5zwwdvksg948SW0EBaTK+REKUasfb4qt2v8PbFB
UyNU7rDoL5LBLUKyxOUYajoU0nSQ1nSQZuj5ctw6xT581aSri83dGjxv+dxr3Tp0dMBqBYCiIphM
WLTI6xnnz2Pu3OBDv30bWi2WLweXi+JixMVBrf6B22Qa3K6pXmWYTO4lS1rNZndra6FKNaugILy6
+iaAV175fvfu77dvl16/XpyVxW1tNQdtwm733H9/68gI0dU1u6SEv3Ll5e++s054cV89mDBrV+zM
JzKWnjb0fDl07e/++247uNFjBDNqanjx842aWt9qcLi72net3u76NDB1kQy27YvJ2TzZGTc0QC4f
sxo8e9Yf086c8aeuzZv92aiyEgAqKzFvHj77DFu2YPduDA4GyVujd2mcKNBC/KHiLt55EhXt6b+0
x+0cDtx5mpEGURHoDDLQ3907T2mLERYH/RXoLk7lztOv6L3dITWG1L+R7Vf1iZ+l2V9Grd7G56gN
dQoKCgoKCgoKCgoKCgoKCgoKCgoKit84/wWz/YzD6eCODQAAAABJRU5ErkJggg==

--MP_/570Ji7JA+YU_G6PSClioNnl
Content-Type: image/png
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=vim-bash.png

iVBORw0KGgoAAAANSUhEUgAAAIcAAAA2CAIAAABiEx2NAAAW1npUWHRSYXcgcHJvZmlsZSB0eXBl
IGV4aWYAAHjatZppciu3FYX/YxVZAqaLYTkYq7KDLD/faVLKk2THdsURSyJFdqOBO5wBTXf+9c/r
/sGPWSguW22ll+L5yT33OHjR/OunP3+Dz8/f56fV92fh6/sulfcHkbcSz+n1bx3v4wfv2y8DfYwz
v77v2vuT2N4Dhc+Bn5+kK+v1/nWSvB9f74f8Hqif14vSmfQvU53vgdb7wGcq79/8Oa3Xk/53X96o
RGkbF0oxnhSSf/621wzS63fwW/gbU+W4kCqvU6rueervwQjIl+V9PHv/a4C+BPnjlfse/fI7wY/j
fUT6Fsv38Y4Xv/lBsG/vp8/rx18vnD5nFL9+QHHlH8t5/967273ntbqRCxEt74p6gh0+huHAScjT
c1rhUfk1Xtfn0Xk0P/ziUtsvP3ms0EMkK9eFHHYY4YbzPK+wmGKOJ5KTGOOK6XmvkaMeV1Kesh7h
xpp62qmRvxWPI2c5xc+5hOe6/bneCo0r78ChMTBY4JTffbj/9uFfebh7l0IUFMxSnlgxr6i6ZhrK
nP5yFCkI9503ewL88Xin3/9SWJQqGbQnzI0FDj9fQ0wL/6mt9OQ5cZzx/MpxcHW/ByBEXNuYTEhk
wJeQgJnga4w1BOLYSNBg5jHlOMlAMIubScacUomuxhZ1bc6p4Tk2WixRb4NNJMLorEpuehokK2ej
fmpu1NCwZNnMilVrzrqNkkouVkqpRSA3aqq5Wi211lZ7HS213KyVVltrvY0eewIDrZdee+u9jxHd
4EKDsQbHD96ZcaaZp80y62yzz7Eon5WXrbLqaquvseNOG5jYZdfddt/jBHdAipOPnXLqaaefcam1
m26+dsutt91+x2fW3ln98fgLWQvvrMUnUzqufmaNd12tH0MEwYkpZ2Qs5kDGqzJAQUflzLeQc1Tm
lDPfI01hkUmacuN2UMZIYT4h2g2fuftP5v5U3py1P5W3+EeZc0rd35E5R+p+5u03srbFc+vJ2KsL
FVOf6D7wZIfqMpO10M4u0VpgWr01kkEoO62xdjn7VOCszNC4gvXBkJsFpdpTZGm+3z5Lc+WkXVsy
Bl0xb9Ap7Ew7pbprqI0ABNZzGouezHoHxo/51kOczuK8znllHhBytnZsHvgsEyNistpuq1BDqewV
7wnLjztGM3B69ugJYwWx7zms/PR+SG52Zj22Ww7JCaVxVrZdE0B91lhnD6olw8GpTkJSFV6bY3s+
WYfoTNK2d1rLNfLe9iUqoQvib7daxRRtRCZLjG4PBLxSHatwcDn+0CwEbpxU7ih35jLAo5RIT4pW
6l2rJzttw75UlQ0Lt9RAMdRsFMEqKdRUBlNl+U9Uw6p2JtVVHBVR4hqjl7hhDGiNwj7zNrNz/ajC
sXvVRXvvkyvMQ8dMrSlWvyD8Xigv76rdOigfgsfhjUsvv6bvpGKE0aEgmGdy9V7uXrWs0c81Fh90
/O6DSk1hDFfGrcXfniklf2m41p/uPqvMPlh+vzP1dYDoMqmf1tahK+IsPd7IKZHajme5nNT6xmzD
KSwTuEulzXSQL4ty6NRAaStfJjciAZgKTNi3L0PVFd6jFOZ1h7Kgv6ftODYz6iT2MEQHN6Alb+3W
ShPkXvRZJnBpr9InuigSNk68rTIjNdqCkOfeLH/2i0bT6uMy2uCWcGhR1hTnAAwGT5cT7OnOQlVc
CHufk1zuO4UI8RfPAjrNeCEbqCmm0y3UW9QFd11GOKXMMa/fp+9QaJm4AsUVIfbuSg+zlJewq4Ni
fNX33BncSKSIgp8jGGUUu0+ZQJAZJAU9UPPZO9Ml+UwI0k5PB8hgbt32aS3a6mEDWzese9acaIx+
qZMFGPStHs+bDtuEGj0yVp7lupT7MYDh1HoqpUjjEpwDKqZ4hp3YgISTAIZJYQigzhklw68M5Wva
ZdAtezrwVp0P4KJiQrmFhHp6nqbK0fKsJxn4qXBRI75ZUhpJWBugO2AAdN3ZltMiV0ikpO8T0o7T
JKDSPpPGIYoII4pz+cPVKZ0EWKqDldl06CUK71LVLhD+RJBb3SnPzXpm3gCd78a1SpjNGLAwlm/k
jtPzIKLUyCg2SIVqPpXgRvWT+qX+QqmT7DVPm2+fpk7i0LKoHaFDh3vG3szdJrlJieHjBURPnXe7
79NMd7KUCd6QngsFUn2BTq7jWjsDMUMlB6twWwPbMp1zetzGQKf41MLsNCsgdpmAR12Gka0lT0+c
UluIrGTChLwzUJvUJjzcIA0okFyhRjrF10vem/Cz5AKu37z9IFxg9qH6wqn9Z4APcSwAK0U+uFJx
Mzdg/+RFpARYDEXUpjV/hVTkNHAVSnUtOS4k28bwkOcJFEt16ySC7w4nUVT35kX/V2FSBd0TUuF2
mLw0CBax3kM49B0Fe2hEAgBBj1Fp17YjSXDU6ZolE93QLB6QeNBruS64de2ZgSNAMiL2m0dHgAko
hrovOc7APgFYkorTJXo+95sYu0tLJRUs4Vt+1wXcw2yGakgtzlgL3QKUei6RRK8RqhGZYCfdeP7x
/g+eGZA5n9sm4iEP0K2cwmsPlEdPKaAhU0QbLMIJVPi1Fh0CyJCpEl780W9b8C4lPyn/wnrF3IPg
wGucQzvf7tJGW6gkWM7J1O9YxOGiGRYqOklowZyIq41duRiodQOQBHFdmAscIXQRQnCWtkWqdYLn
5BkdVzZVRuYkTzKmKc81Wxrwvjeh04lMJEgqMRyCxZPLg8tGReOlRkRSkMWYEZU5wldQ8Gr5eAl6
wnkbUY31gisPo3UwiqaIw1pdyFe38WCwwA7MEyKcsDR6a0qz9FIoiSOVgTKzSzWDYhPKkZ6DRVgl
IEvTgDlOKijBkRE2p8grVI3NA76IBEuna3cDfre4B8EV1T6MKumHFgHwKIraozk0rfw/ZFsXR55+
oZCY6ZnX1KlOEZfUx0KbSWN2JBRT6UDUGKgLGJSsoS0tDvQpBYrbadc86TsVjCZrZ0MedCWJAMFv
9bGK+hGJjX5g6vtCP/hRRASpRT9wTRRWmFCJr7B8TmhUNPjao2FLA5+nBdGvhu67hs/wX6fqmqDs
WyZm7OQYbd8wa+gB5kJlHMw6oHX6tCIAB+tR+FtQTzwci0IAAfMCCvML7lirocUAnlwUbVQhsgm1
s4ewB9aHf3nUCkUvkP/iyoeLuZAfOBR4gqNpoG8VnGHtu9IDalzmqvC7lAGSedjaVg+YmBw4QLwH
pNXT3Mjb/mAe2YKAGiFmIbQBy0fnBsk7D/iFMIesjwePuDrawwHR5A/XZDWMyZXL6sJmKgsSx+ys
yi8yb+vwnlTF1nrkulJmYRQfB3LKcU36Fo/zXhE+4aMrkYhkAdmyYFHQDAYn9AhkdDGoUr1KzpDh
0I05vAa6hfqdCe9DYQDRIPeZBw0rZdrQE0PehOIbGRoTKBdmBqYQcgQ0RLuTQ9kDWIcIcBSClYR1
eTP0BCqvftTGR2X8KHQpCOB0OEolwT0R6dwrmo5MZGr+CGSh1tYqNYqAGI3iWbQ6wgJyRZEyf5SF
BAuElhyYKe1UZ0S4w+rEG1aWUoLKEIK39YCJQLGI2rpGmyAGMLFU4Km+p+g+5/h9EWMEpDA4GTcW
geKGxzGDIAlzjAIu6AbLZGHHa9FNBNn0skgILNFFRCEWcBglgecgVczLMLZzY0amZaaIrh7g1kDe
o4078NGu44SFbokvPWgY2J+VHH6WhoUFehbMs2F9864OtMZ1ohkIKWIFaGO+hJaZY0SW1hRx3YQU
1QrigVRFu5HUbzIcSZwnT+LjNlxMFOF9XHHCJxlO11IVH6QqpAO14sOKY6saJhyAqQP9G1Cc9Vob
re7jxf/6/H8ciKYj8rZzNaSO9Bssv1B5ol+qEGuANAFVqSKgELQI8EFFHk9fJvmWDsXWrAbX7m0P
2GDjBqrkDhzuBcdKG3s+fjwNdEBD9lR0cIaYHZhxRqYSJoluKm7EIA6d9CFMaIoBBWDL88xgL5pG
RH52wdUOhBzqdUhLTgfsYGvaekC0IVQ3TZ1JjBj54oYwqDKuHvONP5cs7ni5kqjExDrpUSwwGrIF
tTylJziXkli47js8Fc2qGLXDqrArZYMihl0iDILGRVpK8aQGuoCuVHY+Rbsp46Ad/EH9zNAp8Yec
D9iKPkwzDtaIH6ZTEtqnMT9ecRkPPCUjPgyEI0ekYj9xUywJeUJlgym9apuVKSxSMPBiMFvCF3IN
cscscZnavwXKEeWOpKBggHNNEZOy1LoN/9AWyNkxXRu/Zz5LoWNVWgE/+RjOZGIYurFRsSU56zgH
1MNEPweA/XEolZYgMzOSvegZ11NBSGLOZcEX0CbzhLFxqkEjWFLX51CI8BZQZsTzbUgdnhuySda1
K4EGI4l8ynDEGr+EhIdVobR8mHEB245bJ1iEKjcaGRt8I6IWRLaLpEA/5EYbPzayikxY8dTSGkqB
8qeA2gSY+zBH/RoyJ0S5ukNXBPCGCxeplXUzDI3KBCx46ARpoUQ1ArBBzDPQFiQ5oUaY5YDCqwAD
XL+FHoBIEecsDz1YpGR5GVrU1GLEyrWBGKrQvQwi7rkfB+aiunpFsOwIVkWmTOvW4esC2f2mLmhY
mkfiGAsAOM3ZmK7RrggXydLtpwOxaADoE8aIlYtiI7FWeHUEFiciNQJwXw42EU2WvPa74OZdkTcp
7Kxdh9Gjo4EAZPqSzkbMniLgHirnfX05UFgM5EW8mofIh7gjvMteVBo+NS5mAry6g4qgLcske5TI
C+IfK0PCE93jCXEwqoiQdL8IDnQIp5WUcUaPHiB3+LUK5Eit4cspsEjpL1RfQ6TBPAPBrg0q/Dtg
hLY1veoEyZBAuEVAAl/gw3YVaYTGWkn7VwWtEj1SkjKgc0tQsrVHih2E+IiRNrFIqnSFJcQdugrZ
Q+actkEPEgvdwEWW2BDuYX7avaYxwEfQBV9A4L30UskgJC0VOX7CP9Q5o3r3bFTBvVZXeE2tznqx
ixgKwBPspiygUMygIb07iwFzwaRHLaarCA262pE+2guoAEU4VQrvYG8BuQky4iwGklR3gS7ZVs7S
i3GTjoPBtasTABg3Q3g2hELdpUZE9ZRznxXQbOC9PEf0czFiQQbzV34TfOVI6r/SiAWOPRl5zEyR
HAtLJnSjG+gpXdVr/6ADArjXY5jvVFNpJtdAoQfJNOtZ+60AUpBg71y7G9aCwnqAE8AhJjE+ZRGJ
BcJ6MwQwkPlM2QgqFow92gT/UeJxQDiJmbI/2OP08rCTK6HYppz33F0IiwNBuqm3l4x9ftxe9gU1
iK4AanfAE6EPoloYpSOxtY8KEpvXgTbOBrdzjQI5wfCKKGL0ctIWYn/2h+5cLtrRlp92UxE2uQY/
G9amnUKcsaXotoOrpaNYAy2Hst5oHep8a8e3aPNqmK+OwfAQecK99D5CFo8tCb5yHvlchkqZqMJS
4CN4lgz4LAlVEGq+GBUCWTnLNTIMC0vPYYCUoAks+MRfCHV4iIpQge8bTITBDSqTeoja0m2gV3jt
WjoS1E/TDREcZkoZHRKBN2RilGjs/gDp2s5pQVv/kLOMGwNi6AHbRKkc0abDBiwMxUIkF9RYseHx
ZLS20W9wCx3MsjC60KVpn5u8aDuH4imVft+X1k5xOtpLCgU34ad2WBG8KOEkr6ytvY6CPC3dHWBO
0CUj/rBwgaua5Ao0qjsIBd8fFnYhey9FA9AuyV8mDFBPVDog27FnHDuabgJqD6nS0giZBlFXKQgV
2XI059o4p0m1lEHz4LCwdSOrNTbrXP6VfOYVrlQTSgbPQXlB4AQFzgYcE8o/12KMhlC7SxsmgDpc
IiCgMljZhvagT90poAZJDSpF4CUdDUBMbVKk7KDKDEnDWpcYk5QibQPMU7GzebqFzHncuqfmTRg5
ZgsjaZ8JC4vWoWr2bg7TgIWcT/nI6oJbjfpM3ufitU8insPDMKfBfwAG8AgFQ0/J08D4PeIazEHo
CJP5wPpaklgsmHwcPOfuuvsNLuhWEnYCcqvHtC1c5wWbN8bV8Iq8Ux1yhyoiuwQXXVsy2TLJGaC/
UZX8waSRcSz5QmWiubADG4Y0baZTJxfcbnjao9thWzoFtVXlUyA0bU5GKa+LKWIpj9ObtdI81Msa
u2uPunrPFPFztIALBLoAUNsf2nQbnRSn3FyhVw4uiwvlzf8zo0HB+lGLh6/6DWlCIACfR4dtZ9kD
AwhH3YiQfJp8tmXv8S+cAPgm7TV0loNU8toVEBjj4D1cl1K6Yc7UnBqwHkwaYIx1zFt+kuDjn+KV
pF0HpQPIL23uoN0WKAQBTmBoEAA8RwNgjkOnYaqvbqV5+sm87nOVjUuw5yZQQU3d+TiJTCovYopK
I6uk93G/VwBQjcqOkkKi9dyVYoXidEMNg7M4tgHwoxqaRyehPVdoSX1e29XO7EEEoYTXdnQkAk4f
YRD2QCMU3SnAE90a0BDRqyq6JK7hrLWbod0OmIVO7adqV6i2ch1yixPyaz8lY5wRRgR7AfZcB7Zu
2TMNahsfY4KIJMgLalnMvTRKGtNfYKR13a2s0Ig2jzks0t7A4bNBBmCCl8i8BfSnjFPO7RmWCeFz
T7llcfk1XAoAtfbxJNCVO+1JNkAQyIf+DG3vtUVcoexB9AxP+6hmTC+69NnrMu2N3BPgUeiZWMKH
BVzQduRG2l/CjfiXMu74LJyGKUXq+A6eQKi67wcjAsTHpag9vCdRaElZifjc1VkzI44JF5fM+m4F
viZqb0PlSePhxAkvhuScRYPB/WtRZWBMf7aIGQM/QTXoLg/1x0wFU/oFqcNG/lPXaESw42y6IgQa
Ge/lMuEbuo2L50NjPrfCFD48haHpAkSFHN14iiLzULS7jj0u8AvUEJ/vxuiOk8P8qH3mQ21U2eN9
aBvtq6JYwNzFHGMQYgoYdNdW91kX3Eco0CcNrZfKczujKMUZJxB1jdlQeD7DatBC1C2NCQoTVlQM
RKtvCrCqBLJqw7ZAdMAlqvawgCLe3HjqFwFb0B7lRcP0+twtYl4kNYSwxIDoGuAR4+IRjahWjOi4
DERVYdrGwpJhePfxA/gQjOkLEDNvSgqJe7Qfz+UwvYJN3L5cqm5gYaanNwehLiq8J+k4cGTRAzUg
jTZFSFdgEloJM3jVGj3pZa2AUO0koM+S7uaiNaeDlax4zkH5+6IocCzk+yxphzGz0HE89/VhvSLW
29ppV7CXbtEtT9MN5597ZgPoPBELfA1oFIEJky8KTvdkTYpo2GlAOlErA6us3fWtgoiPRzEn3AeG
G1Isa9v6pWcRiw2tgXJeIjQiC+VHfdEBXVzlQei6Cie0LF6ZaTjEEuJMX1JAVlCrD3B33eDVjUvt
08Eu+PyCnJeQQstjJoCFK/iWsE74/3Sc9koBgCBbSSVSbZXC3fr6yLlB+x64T3miPn1H7Dbc8qzE
B92NUN9I3ExBoI8Ud+RHeAwJoIzUHVQWjgRVAvg03bGRAGkyDCmokZn2xRBQ5NRSTYikivHjcrFP
pd0DOnMDDvxcUOXZ+dN+jJ0p96+tQxqT9NkOhusgegBZIWLJoX/Q44FioLr0jQDBEwIkYHjxMIjJ
R2xWPkd7YyH384UBUB9gINWlgqG3BffewjtM5s9uqGUwTWimL0LKPGq/pLmuCHZ9B05frNED/oBS
JPt7FZltILYjTvfH7TRcw+uVvtf58ey+v/H1GZszKa+eAQcKkXqA+7Wf2yAS3XbdCVIF84OjutGN
XB0LhaTpR3fNu3SYRclC+QndZLa6JWZR6WHRAGvAkUAJUhDJODSjheHuGWVMGcIy7RWz+Fe3It3f
sJf5baCq2+beu38DUBaPHRI19gwAAAGFaUNDUElDQyBwcm9maWxlAAB4nH2RPUjDQBzFX1O1IhUF
O4g6RGidLIiKOGoVilCh1AqtOphc+iE0aUhSXBwF14KDH4tVBxdnXR1cBUHwA8TJ0UnRRUr8X1Jo
EePBcT/e3XvcvQOEWompZtsYoGqWkYrHxEx2RQy8ogOD6EUEwxIz9dlkMgHP8XUPH1/vojzL+9yf
o1vJmQzwicQzTDcs4nXiqU1L57xPHGJFSSE+Jx416ILEj1yXXX7jXHBY4JkhI52aIw4Ri4UWlluY
FQ2VeJI4rKga5QsZlxXOW5zVUoU17slfGMxpy0tcpzmEOBawiCREyKhgAyVYiNKqkWIiRfsxD/+A
40+SSybXBhg55lGGCsnxg//B727N/MS4mxSMAe0vtv0RAQK7QL1q29/Htl0/AfzPwJXW9JdrwPQn
6dWmFj4CeraBi+umJu8BlztA/5MuGZIj+WkK+TzwfkbflAX6boGuVbe3xj5OH4A0dZW4AQ4OgZEC
Za95vLuztbd/zzT6+wGTlnK0Zn+JQQAAAAZiS0dEAAAAAAAA+UO7fwAAAAlwSFlzAAALEwAACxMB
AJqcGAAAAAd0SU1FB+QGGxAlJxiGEPYAAAshSURBVHja7Vt7UFNXGv9uXiSXhPAmCUl4PzUhIVDb
FRYUWxirHa3btbVVcRyxUxmnXdvOWrs6rWtf29ZH7SwPt7WP7e5s6y7W6QrVKm0B3SogD0EhFppA
eAQCeb9z9o+LIcijSOlsYe9v7h/JOfd837nnd77vd3JyLgCJXx4wACiCq/8Pj1oGGQulq5T54ZYC
75jlwWLGlLV/VC6NWeY/vzZngwMtqcl5nIU4gcZZ8Q+mHexcCgC7zsTH3jc+iLH3+R8zybFJ9PFT
mX/qkzJwCgCExfkhBCNqx5Q+Xoxv7fqPeTa9mb3NHwWVjkUkMfvbbQublehM/IerZgAQy3H1Nau3
XCTDe5osyHNnyzUHBF++OeCweAAgUsLqv2FD6Kf2Zh5t8pKZTqtnVONc2KyIFXj3FUuQiGEadjmt
Hl9W1I3WyZM68dfsr/+sJb4Kpbh52PXM+cR3zPKnKuJoDAwAKFTsXXt6KVI8922St6FsXeDe75I3
HhUdM8lfuJrCDqXdlU35w4GlSFGKFIdHZBuPirxt798T8UqX5KhBtvX9aCLUIiWsgQ77lI4WBivR
9/iXIsW6Q5GPvCV8TSURSlmlSCHbab/NCkvVYJlhUgNApJQlkuOnnu/ZF9cqkuOK3wYBgMeNdvk1
fL5f09M0TqpQygqL9Wv81+jvhc10JiZdy70rm43/HN2J1e/E6g+mtUnXcpNWcAAgZVVA7lNhR/M7
nxc061QOfiqTcBQaw5jS0S8fNADo/s78JLX+9R7pCzEtG94Qqhoslz4YBvDzpoLvL5kmB8oH27q9
JZES1ukXewny1I0WLp/uG2rXK/XjrKThF49rO6qNAGAYcDnMnjnYBACdyqFV2gN4dADg8ulmnVvf
77SbPGcOaLzNp3S0kDKYUIoP3LS57Cgxh0M8CQFOOM1pR30TNfOOSc3AKWGxfk2nx4Y+UMgY6nL4
sMLyVSlhGqvtnME7cL0t1ruymV0UeqAl9bhFXooUKfcHDHfZAeDqP3Rt5wzPfZu0uzLBu9iLlEzt
aMGw8pY27cXGlMRcTilSCNNYr3RLsneEEtXGQdez4U0zKAoACJaykAcZBpwAECRk8FOYnd+M8crk
UIPFjN7WsRHxY1NCohm9zVYACBTQmWzKQId99jbTfxP0wLO8E5u6dnOu7YttdTmQuskKAC47qnih
92BaW/s5AyE2LC41MHIKRwspg+0Ja3rqdNz5twfxIKpsXeDJwvE0suVElNOG/lasmi5QiAxOoWFL
CgJ6mqyby6PqTg4bB13eyBhU2r1rB6EUH+py2IxuIpX1tlo9bjR7m2I5PthpG+lx8FOZT5RG9bVZ
nVZPzDL/ezYFf/nmgNPqicrANa1WIji039snO1pIrNBZFLEcV9aYnigTN30+6lsdnsBsODUyg6IQ
Q/BNqXbjERFXQL/8ke6zPT0A8MjbwlXPRBA3lCKFqsFySNEuTGP1XLN4CSNWAbO3Wfve0M5PY9/Q
SDu+Nnnjr6fZmrER/aExxe1CzWf0n+7pIZpPdrRod1x2/D22+4r53FsD89iDn8PmQt9xIffBFu8+
GAkSJEiQIEGCBAkSJEiQIEGCBAkSJEiQIEFi8QJNdS22J0IIcbmzPf101/+vuFw5lZXSn+NRguJA
sgnStiyGiRafD2lbQKCYY/P/zb9ekfe8RmUE3lHIk0FfIzR/NHZD3AMV41VpzyeuuUh85kTmKYoQ
T7aX+MoMTFYUIUURkm+3pjzcECDMn87p4cPxCOVKJP4AgGGg12fV1sqJqmPHEhDKra8fH8WKiqUI
5bLZVG9JYSEPodxHHw0HgOhoJkK5JSWJNBqGUK7v9fTTQgBQVkHnv4GvAIy6EFhhBqYkPfRNhPR3
yesuBcVs8K2iMcEyBMTBYoP6LEeQA7fPnHMiVxrUZ4nPgeI1luFrgVFrfds2/oXV9EGwTvlx3AOn
JvNNoKZGDwCZmQEAkJiIBwTQamvHDoytWhVkNLplMnZwMH0OD1VVpcOwauI6cqSHKLQMAXIDjfkT
WFmyxP/iRZnBkN3RsWz7dv7YMNGwl16K7uq6V6tdfuRIPJ2OEeUREYyaGrnRmH3yZDJRkprqX10t
MxqzW1oyH3wwZAZ/4qx3jZrqwdZ3ui5u5k4cWQwbFxTTQC0ABQ9NBwCMQmfzsvS3WeGKH+yrfwkP
U9CYYb7NPS6rtq2EQvNnchNmYCUjgwMAmZkcAKit1QMAn89IScFLSjQUCrZiReB8ygsCDJsrKzhO
raqSMhhYdPTlsjLNiRNJROf27hXv3x/9+uuq6OjL16+bJRI20SYmhrlpU/tnn2m3buVJpWwmk3L2
rITFosTGXq6r01dULE1KwqfzR2OFG9SVyOO065Xd1YXecv8woDHBcft9CuRxGXvPBwhWAoB/+DK3
fdSqawEAJjeRzhYZ1JWWoWtc8eoJpFL9QhK3uuw6m/6mb845fnyMpIEBx61bVl9W6ur0RKAAQHm5
ZmjImZcXNI+sOEzAFQFGmRMrq1YFRUb6lZf36XTO0lINABDZc9s2vlJpLSnRmM3u8vK+hoaxE5EN
DSaVytbYaCImWk5OoFjMfO+9fq3Wefx4L42GPf54xHT+BpreEGW9y+Zl+YdnYreTbnwBJK+HwVZw
+Zzb0qvPcgQrCCEZD5SoteaBSx63zai5wBWv8d4s325N326LkD578/Sv3A7DdN5ravRSqT+djmVk
cDo6LFqtEwDy8oIGBx2dndaaGn1e3lxiJT8/2KsroaHjOVBzBUTL57J+oQCAUOgHAO+/n4xQrsGQ
DQBRUUyiXK2e4iCow+EBAI8HEWmHaD446ACA/n6H1+CUGO748FbVQy6bNiSxMHn9FRozlNBGZSWE
SyZkYYO6ks3Lwij0AMFKn/S1xqi5AABGzYUAUT5GofvoSojD1B2atN1r4eTJfgyrLi7u9JbU1ur9
/CgyGVsu53hFJS8vKDycgVDuunWhiYn4DJ2fja4MDY2/MSPIhL4GaPpwTqxoNHYAeOyxNq/pgoJm
AOjpsc+mi729dgAID2cQkkM0nDGu1bbRm6qaXbbR9pCkbcT6Xq8CjwMYbJ/bzD12YxeHn4OHKYy9
5wGAyuCyecsFGQcVRShh9ZdUOofDzxlfstt1qprisCXFdJw/Q6wQmY3FohCikpSEC4V+mze3Y1h1
UtJ3BElTth0ddRFaCwCExOp0rplHhsGGkVuAPHNi5auvRvr6HLt3C0Uiv7Aw+rZtvMJCHjHXEhJY
RUUCLpe2Ywc/PX3qdwyrq0fVanthIS80lF5cHOlyoU8+mfYgZMzKj9m8LIzKoON8Vkia09LnrXK7
iEODE5IYX7HfrL1KJKUAUYHLrqsvp9aXYfVlmF71xR3rBdtou1FzMXzp7il1BQBu3LAMDzs3b+Z5
pZ4QlZYWMwAolVaLxT0dK/X1RqcTrV8fyuFQiQx/6ZJ+5sHFMHC75qr2RqO7oKDZZHI3N2c2Nmak
p3MqKoYA4NVXfzh06Id9+8S3bi1LTsabm01TmrDZPKtXNzudqKvr3qws7oYN12/csEznT9teJsg4
GL5kV+KaC3rVF7rOv45PdhvgoROIMajPsnnZBnWld/U12l3hnXsjXad8pYXAYMvhsNQnZ1gU1dUZ
OBzq8LDz5k0LERkuFyI67PGgtjaLr7QYjdmEWlRXy9Rqe2HhjdRU/8HB5Tt2CF5+ufvMmeHJukL8
XgEAVghgVHAtoPcyJ/6KHNuTCI5Hkk0obcti2HGJz0dpW5AgY447Lr+gtwV1StApF8nWnrKK3J1c
dLuTJEiQIEGCBAkSJEiQIEGCBAkSJOYb/wWWRm8XRe3aawAAAABJRU5ErkJggg==

--MP_/570Ji7JA+YU_G6PSClioNnl--
0
leonerd
6/27/2020 4:40:14 PM
--00000000000025190205a91394ea
Content-Type: text/plain; charset="UTF-8"

On Fri, Jun 26, 2020 at 3:43 PM Sawyer X <xsawyerx@gmail.com> wrote:

>
>
> > '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.
>
>
Just to address this first: no, it is a major reason that "use v" is the
*only* suitable method. I will explain further.


> > 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.


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.


I disagree, with both the premise and conclusion. It is in use, maybe not
always explicitly, but via modules doing the exact same thing. Mojolicious
currently provides the equivalent of "use v5.16" to all of its own and user
code, plus some other useful things like "use warnings" and "use utf8"
which we should really consider adding to the "use VERSION" functionality.
Any time which I could use "use VERSION" and did not, it was only because I
end up having to add an explicit "use warnings" anyway.

There are two things that can drastically improve the experience and
visibility of "use VERSION". One is making it set "use warnings", so that
it actually is a meaningful reduction in boilerplate, and then can be used
all over the docs and tutorials. The second is having meaningful major
versions as is being proposed, so that it is much easier to distinguish
what a "use v7" might allow you to use from what a "use v8" than the
difference between "use v5.14" and "use v5.24". None of this requires or
benefits from changing the default features.

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.
>

This is a moot point unless we actually change the defaults, which I am
arguing is the error in this design.

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.
>

This is misleading. unicode_strings does not do this. unicode_strings
causes a specific set of functions in that lexical scope to use Unicode
rules when determining how they interact with a string, instead of possibly
using ASCII rules if the string is downgraded as the previous heuristic
did. This is completely incomparable to issues where the string *contents*
are actually different. It is exactly the usefulness of a lexically-scoped
feature, and I would argue that causing hard-to-detect problems is *more*
reason to keep it scoped lexically rather than affecting code that did not
expect it, particularly that you did not write.


> 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?
>

This argument is self-defeating.

Let's take three example situations.

Situation A, I am writing or maintaining code where I can use an arbitrary
version of Perl for the features I wish to use. I probably am currently
using "use v5.20" for signatures already. I could just as easily change to
"use v7", as run that code on a version of Perl which enabled these
features by default; the default enabling of features does not impact me in
any way.

Situation B, I am writing or maintaining code that is developed for a
specific deployment of Perl. I may or may not be using feature bundles. If
I have not yet upgraded to Perl 7, then I cannot either "use v7" or use the
features that are default enabled. Once I decide to upgrade to Perl 7, then
I can either "use v7" or use the features that are default enabled, because
I know it will be running on that Perl for the time being. There is no
reason to use any compatibility module since it will only run on the
version of Perl it is being deployed to.

Situation C, I am writing or maintaining code which must continue to work
on older Perls, probably because it is for CPAN and I wish to be polite to
users. I cannot currently "use v5.32", because it would mean the code
cannot run on these older Perls, by definition. I also cannot write this
code using features that would be enabled by Perl 7, because using those
features without enabling them would mean the code cannot run on these
older Perls, and would not even have a nice error message to indicate this
problem. "use compat" only allows me to write code that will work with or
without these features enabled; it does not allow me to write code that
will work on Perls that do not have this feature to begin with.

I am sure there are other use cases with differing tradeoffs to make. But
taken together, I think that this shows that any argument against the
usefulness of "use v7" is also an argument against the usefulness of Perl 7.

To summarize:
>
> * With "use v" I need to add this *everywhere*.
>

With Perl 7 feature defaults, you need to expect it to affect *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 Perl 7 feature defaults, you need to deal with significantly breaking
changes all at once, even in code you are using that you did not write, and
cannot lexically scope the changes until a particular part of the code is
ready.

* 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.
>

This is false. The effect of "use v" is entirely lexical.


> * With "use v" the code will not get removed, which is the opposite of
> what we want
>

I don't see how this proposal solves this problem any better. We are still
providing the mechanisms to turn these features off, and we will still have
the ability to remove support for features as we already do. The existence
of major versions allows us to do this more cleanly, regardless of enabling
them by default or not.

To summarize my overall point: I do not think that changing the default
enabled features sufficiently solves the stated problems, to justify the
amount of effort it will take to overcome the breakage it will introduce,
when compared with an improved "use v7" which does not introduce any
breakage and solves these problems as well.

-Dan

--00000000000025190205a91394ea
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Fri, Jun 26, 2020 at 3:43 PM Sawyer X =
&lt;<a href=3D"mailto:xsawyerx@gmail.com">xsawyerx@gmail.com</a>&gt; wrote:=
</div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex">
<br>
<br>
&gt; &#39;use v7&#39; also allows the new stuff to be scoped to a single so=
urce file;<br>
&gt; other .pm files can still be included unmodified using the old perl<br=
>
&gt; syntax.<br>
<br>
That&#39;s actually far worse and is a major reason &quot;use v&quot; is no=
t suitable.<br>
<br></blockquote><div><br></div><div>Just to address this first: no, it is =
a major reason that &quot;use v&quot; is the *only* suitable method. I will=
 explain further.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
ding-left:1ex">
&gt; Look, we&#39;ve got this great built-in mechanism, &#39;use vx.y.z&#39=
; that&#39;s been<br>
&gt; around forever. It hasn&#39;t seen much use yet, because frankly there=
&#39;s<br>
&gt; been very little call for it, since there hasn&#39;t been much new<br>
&gt; non-backcompat stuff so far. But its been sitting there waiting for us=
e to<br>
&gt; use it.<br>
<br>
This mechanism isn&#39;t in use because it does not work.</blockquote><div>=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Instead, I will focus on one particular aspect: &quot;use v&quot; does not =
work for us.<br>
<br>
1. People do not actually use &quot;use v&quot;. This is what we&#39;ve see=
n with it<br>
so far. CPAN is an example, and every code-base I touched and<br>
discussed with peers had rarely used it. It is true that this is<br>
anecdotal because I haven&#39;t touched or discussed every code-base, but<b=
r>
I am in touch with a few major Perl shops. It is rarely used by any of<br>
them. This has to account for a fair portion of active Perl code and<br>
this anecdote does means something. We have a mechanism we believe is<br>
superior and gives our users what we think we want. Our users don&#39;t<br>
use it. Aergo, our mechanism isn&#39;t the gift to developers we thought<br=
>
it is.</blockquote><div><br></div><div>I disagree, with both the premise an=
d conclusion. It is in use, maybe not always explicitly, but via modules do=
ing the exact same thing. Mojolicious currently provides the equivalent of =
&quot;use v5.16&quot; to all of its own and user code, plus some other usef=
ul things like &quot;use warnings&quot; and &quot;use utf8&quot; which we s=
hould really consider adding to the &quot;use VERSION&quot; functionality. =
Any time which I could use &quot;use VERSION&quot; and did not, it was only=
 because I end up having to add an explicit &quot;use warnings&quot; anyway=
..</div><div><br></div><div>There are two things that can drastically improv=
e the experience and visibility of &quot;use VERSION&quot;. One is making i=
t set &quot;use warnings&quot;, so that it actually is a meaningful reducti=
on in boilerplate, and then can be used all over the docs and tutorials. Th=
e second is having meaningful major versions as is being proposed, so that =
it is much easier to distinguish what a &quot;use v7&quot; might allow you =
to use from what a &quot;use v8&quot; than the difference between &quot;use=
 v5.14&quot; and &quot;use v5.24&quot;. None of this requires or benefits f=
rom changing the default features.</div><div><br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex">
2. &quot;use v&quot; turns on *everything* till this version. With 7.0, we =
do<br>
not intend to turn on everything. If you were to take a large<br>
code-base, you will not be able to easily transition it to<br>
*everything* in <a href=3D"http://feature.pm" rel=3D"noreferrer" target=3D"=
_blank">feature.pm</a>. It&#39;s impossible, even with an exhaustive<br>
set of tests, because the number of changes, both to syntax and<br>
semantics, will require a lot of updating and probably tests you<br>
haven&#39;t even thought of. A good example is unicode_strings. If I had<br=
>
written 10K lines assuming my strings are bytes, I&#39;m screwed. Will I<br=
>
get the time to actually go ahead and change all of my code to assume<br>
otherwise? Probably not. For 7.0, we will turn on very few pragmas and<br>
features, to allow people to make a relatively seamless update. This<br>
is already being tested with a few stakeholders and is proving fairly<br>
doable.<br></blockquote><div><br></div><div>This is a moot point unless we =
actually change the defaults, which I am arguing is the error in this desig=
n.=C2=A0</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex">
3. &quot;use v&quot; being lexically scoped is even worse in this respect.<=
br>
Different code within the same code-base that touches the same data (a<br>
fairly common occurrence) will now have some lines of code that assume<br>
the string is bytes and some assume it is Unicode characters. This<br>
makes the code nearly impossible to work with. If in #2, I expressed I<br>
can&#39;t move a large code-base to every possible feature and pragma at<br=
>
once, the fact that it&#39;s lexical can only make it worse for me because<=
br>
I don&#39;t know if a line of code that has it enabled will trigger a line<=
br>
of code in a different package which doesn&#39;t have it enabled.<br></bloc=
kquote><div><br></div><div>This is misleading. unicode_strings does not do =
this. unicode_strings causes a specific set of functions in that lexical sc=
ope to use Unicode rules when determining how they interact with a string, =
instead of possibly using ASCII rules if the string is downgraded as the pr=
evious heuristic did. This is completely incomparable to issues where the s=
tring *contents* are actually different. It is exactly the usefulness of a =
lexically-scoped feature, and I would argue that causing hard-to-detect pro=
blems is *more* reason to keep it scoped lexically rather than affecting co=
de that did not expect it, particularly that you did not write.</div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
4. &quot;use v&quot; is meant to make &quot;use feature&quot; easier. Using=
 <a href=3D"http://feature.pm" rel=3D"noreferrer" target=3D"_blank">feature=
..pm</a><br>
indefinitely makes it impossible to ever remove code, which is also<br>
something we are actively trying to change. This means that &quot;use v&quo=
t;<br>
does even more to cement feature guards&#39; infinite existence. Why<br>
remove crufty features in the code when we can just keep it on by<br>
default and force all developers to indicate they don&#39;t want it?<br></b=
lockquote><div><br></div><div>This argument is self-defeating.</div><div><b=
r></div><div>Let&#39;s take three example situations.</div><div><br></div><=
div>Situation A, I am writing or maintaining code where I can use an arbitr=
ary version of Perl for the features I wish to use. I probably am currently=
 using &quot;use v5.20&quot; for signatures already. I could just as easily=
 change to &quot;use v7&quot;, as run that code on a version of Perl which =
enabled these features by default; the default enabling of features does no=
t impact me in any way.</div><div><br></div><div>Situation B, I am writing =
or maintaining code that is developed for a specific deployment of Perl. I =
may or may not be using feature bundles. If I have not yet upgraded to Perl=
 7, then I cannot either &quot;use v7&quot; or use the features that are de=
fault enabled. Once I decide to upgrade to Perl 7, then I can either &quot;=
use v7&quot; or use the features that are default enabled, because I know i=
t will be running on that Perl for the time being. There is no reason to us=
e any compatibility module since it will only run on the version of Perl it=
 is being deployed to.</div><div></div><div><br></div><div>Situation C, I a=
m writing or maintaining code which must continue to work on older Perls, p=
robably because it is for CPAN and I wish to be polite to users. I cannot c=
urrently &quot;use v5.32&quot;, because it would mean the code cannot run o=
n these older Perls, by definition. I also cannot write this code using fea=
tures that would be enabled by Perl 7, because using those features without=
 enabling them would mean the code cannot run on these older Perls, and wou=
ld not even have a nice error message to indicate this problem. &quot;use c=
ompat&quot; only allows me to write code that will work with or without the=
se features enabled; it does not allow me to write code that will work on P=
erls that do not have this feature to begin with.</div><div><br></div><div>=
I am sure there are other use cases with differing tradeoffs to make. But t=
aken together, I think that this shows that any argument against the useful=
ness of &quot;use v7&quot; is also an argument against the usefulness of Pe=
rl 7.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"=
>
To summarize:<br>
<br>
* With &quot;use v&quot; I need to add this *everywhere*.<br></blockquote><=
div><br></div><div>With Perl 7 feature defaults, you need to expect it to a=
ffect *everywhere*.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex">
* With &quot;use v&quot; I need to deal with even significantly breaking ch=
anges<br>
and I need to deal with all of them at once. (Like within a<br>
single-but-large file.)<br></blockquote><div><br></div><div>With Perl 7 fea=
ture defaults, you need to deal with significantly breaking changes all at =
once, even in code you are using that you did not write, and cannot lexical=
ly scope the changes until a particular part of the code is ready.</div><di=
v><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* With &quot;use v&quot; I need to add this to all files and deal with all =
of it<br>
at once because due to it being in a package scope, it can create a<br>
vast action-at-a-distance behavior. I could trigger code within my<br>
code-base which wasn&#39;t updated or code in a module which wasn&#39;t<br>
updated.<br></blockquote><div><br></div><div>This is false. The effect of &=
quot;use v&quot; is entirely lexical.</div><div>=C2=A0</div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex">
* With &quot;use v&quot; the code will not get removed, which is the opposi=
te of<br>
what we want<br></blockquote><div><br></div><div>I don&#39;t see how this p=
roposal solves this problem any better. We are still providing the mechanis=
ms to turn these features off, and we will still have the ability to remove=
 support for features as we already do. The existence of major versions all=
ows us to do this more cleanly, regardless of enabling them by default or n=
ot.</div><div></div><div><br></div><div>To summarize my overall point: I do=
 not think that changing the default enabled features sufficiently solves t=
he stated problems, to justify the amount of effort it will take to overcom=
e the breakage it will introduce, when compared with an improved &quot;use =
v7&quot; which does not introduce any breakage and solves these problems as=
 well.</div><div><br></div><div>-Dan=C2=A0</div></div></div>

--00000000000025190205a91394ea--
0
grinnz
6/27/2020 4:46:53 PM
On Sat, 27 Jun 2020 12:46:53 -0400
Dan Book <grinnz@gmail.com> wrote:

> I disagree, with both the premise and conclusion. It is in use, maybe
> not always explicitly, but via modules doing the exact same thing.
> Mojolicious currently provides the equivalent of "use v5.16" to all
> of its own and user code, plus some other useful things like "use
> warnings" and "use utf8" which we should really consider adding to
> the "use VERSION" functionality. Any time which I could use "use
> VERSION" and did not, it was only because I end up having to add an
> explicit "use warnings" anyway.

I'm with Dan on this one.

I would probably use "use VERSION" a lot more often, if it actually did
more things. At the moment it barely has any effect besides declaring
the required version. If "use VERSION" actually did turn on warnings
and generally fiddled around with featuresets a lot more like we're
proposing - and a use v7 would - then I would use it a lot more.

I don't think the argument that "nobody uses use VERSION now" to be all
that appealing. Nobody uses it now because it's largely useless. Make
it useful and people will use it.

> To summarize my overall point: I do not think that changing the
> default enabled features sufficiently solves the stated problems, to
> justify the amount of effort it will take to overcome the breakage it
> will introduce, when compared with an improved "use v7" which does
> not introduce any breakage and solves these problems as well.

+1

I especially agree with the part about authors of CPAN modules trying
to be polite to older versions - I have quite a few of those myself.
Right none almost none of them will be capable of being 7-friendly if 7
just presumes its semantics without my say-so. If 7 required "use v7"
to actually turn on 7-syntax then things like List::UtilsBy will
continue to run without the horrible hack that is currently my attempt
to monkeypatch a :prototype() into older Perls. [see other thread]

-- 
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk      |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/
0
leonerd
6/27/2020 5:00:07 PM
--000000000000d1248205a913c3da
Content-Type: text/plain; charset="UTF-8"

On Sat, Jun 27, 2020 at 11:21 AM Sawyer X <xsawyerx@gmail.com> wrote:

> > I think it is not prudent to hurry this process. Currently we haven't
> > formed a consensus on anything because we haven't even had the chance
> > to do so.
>
> This is also incorrect. We have been working on this for over half a
> year. We had numerous conversations on it with a staggering amount of
> stakeholders. The picture you paint is incorrect and in that regard,
> also unfair.
>
>
>
> > Opening up blead and committing to releasing a 5.34 just
> > like Karen already suggested would give us that breathing space.
>
> Perhaps. This is worth discussing once the dust settles from
> statements that characterize that almost no one was informed, that you
> had no room to comment, that it was forced upon you, or that it was
> both done in secret but also not fully done in secret.
>
> This shows an example of the problem we have with the list. The public
> feuding on the process not being exactly what you want is mixed with
> the need to pin down the rest of the details and potential ways to
> move forward. Having to respond to the former also takes a lot of time
> from being able to focus on the latter.
>
>
> > And most importantly, it allows us to bring the discussion back to p5p
> > where it belongs; to take well-informed decisions and to experiment
> > with what is and is not possible without undue time pressure.
>
> This is again, ignoring the reality that p5p is not best suited for
> *all* discussions, only to some. We know this and it is with this
> practice that we ran for at least several years now in which we've had
> core summits.
>
> Now that we resolved to make this decision, the discussion is brought
> back to the public. But at the same time, you cannot complain that
> these details were not resolved privately.
>

I think this is a counterproductive way to approach the development of
Perl. This is not a software developed by a company with specific design
goals. This is a community project where the actual implementation is done
by volunteers, sponsors and grantees, highly subject to their particular
motivation. It is not the details of this proposal which need to be better
hashed out publicly, but the fundamental design and goal.

-Dan

--000000000000d1248205a913c3da
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Sat, Jun 27, 2020 at 11:21 AM Sawyer X=
 &lt;<a href=3D"mailto:xsawyerx@gmail.com">xsawyerx@gmail.com</a>&gt; wrote=
:</div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">
&gt; I think it is not prudent to hurry this process. Currently we haven&#3=
9;t<br>
&gt; formed a consensus on anything because we haven&#39;t even had the cha=
nce<br>
&gt; to do so.<br>
<br>
This is also incorrect. We have been working on this for over half a<br>
year. We had numerous conversations on it with a staggering amount of<br>
stakeholders. The picture you paint is incorrect and in that regard,<br>
also unfair.<br>
<br>
<br>
<br>
&gt; Opening up blead and committing to releasing a 5.34 just<br>
&gt; like Karen already suggested would give us that breathing space.<br>
<br>
Perhaps. This is worth discussing once the dust settles from<br>
statements that characterize that almost no one was informed, that you<br>
had no room to comment, that it was forced upon you, or that it was<br>
both done in secret but also not fully done in secret.<br>
<br>
This shows an example of the problem we have with the list. The public<br>
feuding on the process not being exactly what you want is mixed with<br>
the need to pin down the rest of the details and potential ways to<br>
move forward. Having to respond to the former also takes a lot of time<br>
from being able to focus on the latter.<br>
<br>
<br>
&gt; And most importantly, it allows us to bring the discussion back to p5p=
<br>
&gt; where it belongs; to take well-informed decisions and to experiment<br=
>
&gt; with what is and is not possible without undue time pressure.<br>
<br>
This is again, ignoring the reality that p5p is not best suited for<br>
*all* discussions, only to some. We know this and it is with this<br>
practice that we ran for at least several years now in which we&#39;ve had<=
br>
core summits.<br>
<br>
Now that we resolved to make this decision, the discussion is brought<br>
back to the public. But at the same time, you cannot complain that<br>
these details were not resolved privately.<br></blockquote><div><br></div><=
div>I think this is a counterproductive way to approach the development of =
Perl. This is not a software developed by a company with specific design go=
als. This is a community project where the actual implementation is done by=
 volunteers, sponsors and grantees, highly subject to their particular moti=
vation. It is not the details of this proposal which need to be better hash=
ed out publicly, but the fundamental design and goal.</div><div><br></div><=
div>-Dan=C2=A0</div></div></div>

--000000000000d1248205a913c3da--
0
grinnz
6/27/2020 5:00:13 PM
--0000000000001e1ad505a913d30e
Content-Type: text/plain; charset="UTF-8"

On Sat, Jun 27, 2020 at 1:00 PM Paul "LeoNerd" Evans <leonerd@leonerd.org.uk>
wrote:

> I especially agree with the part about authors of CPAN modules trying
> to be polite to older versions - I have quite a few of those myself.
> Right none almost none of them will be capable of being 7-friendly if 7
> just presumes its semantics without my say-so. If 7 required "use v7"
> to actually turn on 7-syntax then things like List::UtilsBy will
> continue to run without the horrible hack that is currently my attempt
> to monkeypatch a :prototype() into older Perls. [see other thread]
>

I'd also like to quickly point out that this is also an issue for
Test::More.

-Dan

--0000000000001e1ad505a913d30e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Sat, Jun 27, 2020 at 1:00 PM Paul &quo=
t;LeoNerd&quot; Evans &lt;<a href=3D"mailto:leonerd@leonerd.org.uk">leonerd=
@leonerd.org.uk</a>&gt; wrote:</div><div class=3D"gmail_quote"><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex">
I especially agree with the part about authors of CPAN modules trying<br>
to be polite to older versions - I have quite a few of those myself.<br>
Right none almost none of them will be capable of being 7-friendly if 7<br>
just presumes its semantics without my say-so. If 7 required &quot;use v7&q=
uot;<br>
to actually turn on 7-syntax then things like List::UtilsBy will<br>
continue to run without the horrible hack that is currently my attempt<br>
to monkeypatch a :prototype() into older Perls. [see other thread]<br></blo=
ckquote><div><br></div><div>I&#39;d also like to quickly point out that thi=
s is also an issue for Test::More.</div><div><br></div><div>-Dan=C2=A0</div=
></div></div>

--0000000000001e1ad505a913d30e--
0
grinnz
6/27/2020 5:04:30 PM
On 6/27/20 11:00 AM, Paul "LeoNerd" Evans wrote:
> On Sat, 27 Jun 2020 12:46:53 -0400
> Dan Book <grinnz@gmail.com> wrote:
> 
>> I disagree, with both the premise and conclusion. It is in use, maybe
>> not always explicitly, but via modules doing the exact same thing.
>> Mojolicious currently provides the equivalent of "use v5.16" to all
>> of its own and user code, plus some other useful things like "use
>> warnings" and "use utf8" which we should really consider adding to
>> the "use VERSION" functionality. Any time which I could use "use
>> VERSION" and did not, it was only because I end up having to add an
>> explicit "use warnings" anyway.
> 
> I'm with Dan on this one.
> 
> I would probably use "use VERSION" a lot more often, if it actually did
> more things. At the moment it barely has any effect besides declaring
> the required version. If "use VERSION" actually did turn on warnings
> and generally fiddled around with featuresets a lot more like we're
> proposing - and a use v7 would - then I would use it a lot more.

"use VERSION" does implicitly load feature bundles. There is no bundle that
includes strict or warnings, but there's probably no reason why the ":7.00"
bundle couldn't do that to reduce some boilerplate.

https://perldoc.perl.org/feature.html#IMPLICIT-LOADING

> I don't think the argument that "nobody uses use VERSION now" to be all
> that appealing. Nobody uses it now because it's largely useless. Make
> it useful and people will use it.

The disuse of "use VERSION" has been asserted a couple times, but I actually
thought it was fairly common. Maybe I'm wrong. But I use it and so does my
$company. It's nice because of the aforementioned implicit feature bundle
loading and (as you say) to act as an annotation for static code analyzers,
syntax highlighters, and humans alike.

>> To summarize my overall point: I do not think that changing the
>> default enabled features sufficiently solves the stated problems, to
>> justify the amount of effort it will take to overcome the breakage it
>> will introduce, when compared with an improved "use v7" which does
>> not introduce any breakage and solves these problems as well.
> 
> +1
> 
> I especially agree with the part about authors of CPAN modules trying
> to be polite to older versions - I have quite a few of those myself.
> Right none almost none of them will be capable of being 7-friendly if 7
> just presumes its semantics without my say-so. If 7 required "use v7"
> to actually turn on 7-syntax then things like List::UtilsBy will
> continue to run without the horrible hack that is currently my attempt
> to monkeypatch a :prototype() into older Perls. [see other thread]

+1

I'm still forming my opinions of the perl7 plan and still have questions that
need answers, but I will say for now that if I take a step back and consider
what I would want to see in a language that I'm pretending to have no
emotional attachment to, I think I'd have to say "use v" makes more sense than
"use compat::perlV". But I'll keep an open mind.

Maybe it's because I already use "use v" and so am acclimated to this idea,
but if Perl 7 was released under the current plan and I wanted to write
software targeting it, I would be tempted to include as boilerplate "use
compat::perl7" even if Perl 8 wasn't available yet, because I know someday
Perl 8 (or later) will be released with altered syntax and I don't want to
have to come back to code that is already working just to add a
"compat::perl7" just so that it continues to work in newer perls (at least
until any deprecated syntax I'm using gets removed, which is fine).

-- 
Charles McGarvey

Just another p5p lurker
0
ccm
6/27/2020 5:49:00 PM
On 6/27/20 1:49 PM, Charles McGarvey wrote:
> 
> I'm still forming my opinions of the perl7 plan and still have questions that
> need answers, but I will say for now that if I take a step back and consider
> what I would want to see in a language that I'm pretending to have no
> emotional attachment to, I think I'd have to say "use v" makes more sense than
> "use compat::perlV". But I'll keep an open mind.
> 

I appreciate what you say there.  In discussing this proposal, each of 
us has to be mindful of our strong emotional attachment to Perl.

> Maybe it's because I already use "use v" and so am acclimated to this idea,
> but if Perl 7 was released under the current plan and I wanted to write
> software targeting it, I would be tempted to include as boilerplate "use
> compat::perl7" even if Perl 8 wasn't available yet, because I know someday
> Perl 8 (or later) will be released with altered syntax and I don't want to
> have to come back to code that is already working just to add a
> "compat::perl7" just so that it continues to work in newer perls (at least
> until any deprecated syntax I'm using gets removed, which is fine).
> 

My everyday boilerplate starts out with 'use 5.14.0; use warnings;' -- 
because that's what gets me:

* strict
* say
* // and //=
* s//r

.... which is just about all the post-5.8 syntax I use.  I doubt I've 
ever written a line of Perl code that needed 5.16 or later.  But, then 
again, I'm not $employed now so I would mainly be classified as 
"hobbyist."  Where I last worked (four years ago), developers on a 
different, new project we're able to target 5.24 -- and that looked 
really interesting.

jimk
0
jkeenan
6/27/2020 6:09:50 PM
--000000000000a7af7605a9151852
Content-Type: text/plain; charset="UTF-8"

On Sat, Jun 27, 2020 at 12:46 PM Dan Book <grinnz@gmail.com> wrote:

> To summarize my overall point: I do not think that changing the default
> enabled features sufficiently solves the stated problems, to justify the
> amount of effort it will take to overcome the breakage it will introduce,
> when compared with an improved "use v7" which does not introduce any
> breakage and solves these problems as well.
>

To add one more data point for practical impact: Currently the way feature
bundles and "use VERSION" work is extremely helpful for oneliners. "use
VERSION" applies a set of features via a feature bundle, but separately
applies "use strict" - this is *not* part of the feature bundle. This
allows `perl -E` to apply the most current feature bundle, without enabling
strict. For the most part, the features in feature bundles have little or
no impact on common oneliners, so are largely beneficial - greatly
disproportionate from the impact they would have on the average CPAN or
in-house module, and moreso the average script. But strict breaks the
majority of common oneliners, which is of course easy for the user to fix
if they understand the problem, but also is proportionately less valuable
to oneliners.

Could a mechanism be designed and implemented so that oneliners still do
not enable strict and warnings by default? Of course, but this mechanism
already exists: the distinction between feature bundles and "use VERSION"
handles this different need.

-Dan

--000000000000a7af7605a9151852
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Sat, Jun 27, 2020 at 12:46 PM Dan Book=
 &lt;<a href=3D"mailto:grinnz@gmail.com">grinnz@gmail.com</a>&gt; wrote:</d=
iv><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:=
1ex"><div dir=3D"ltr"><div class=3D"gmail_quote">To summarize my overall po=
int: I do not think that changing the default enabled features sufficiently=
 solves the stated problems, to justify the amount of effort it will take t=
o overcome the breakage it will introduce, when compared with an improved &=
quot;use v7&quot; which does not introduce any breakage and solves these pr=
oblems as well.<br></div></div></blockquote><div><br></div><div>To add one =
more data point for practical impact: Currently the way feature bundles and=
 &quot;use VERSION&quot; work is extremely helpful for oneliners. &quot;use=
 VERSION&quot; applies a set of features via a feature bundle, but separate=
ly applies &quot;use strict&quot; - this is *not* part of the feature bundl=
e. This allows `perl -E` to apply the most current feature bundle, without =
enabling strict. For the most part, the features in feature bundles have li=
ttle or no impact on common oneliners, so are largely beneficial - greatly =
disproportionate from the impact they would have on the average CPAN or in-=
house module, and moreso the average script. But strict breaks the majority=
 of common oneliners, which is of course easy for the user to fix if they u=
nderstand the problem, but also is proportionately less valuable to oneline=
rs.</div><div><br></div><div>Could a mechanism be designed and implemented =
so that oneliners=C2=A0still do not enable strict and warnings by default? =
Of course, but this mechanism already exists: the distinction between featu=
re bundles and &quot;use VERSION&quot; handles this different need.</div><d=
iv><br></div><div>-Dan=C2=A0</div></div></div>

--000000000000a7af7605a9151852--
0
grinnz
6/27/2020 6:35:32 PM
On Sat, Jun 27, 2020 at 06:20:38PM +0300, Sawyer X wrote:
>We (and this "we" includes you, Leon) know for a very long time now 
>that p5p, the mailing list, is not a very practical place to discuss 
>major changes.

My objection is that the community didn't get a chance to discuss the 
changes at all, whether on perl5-porters or nay.  The changes were 
announced after being decided by an apparently closed group---and were 
already considered sufficiently finalised that a book has been released 
by one of the group about preparing for the changes, announced in the 
very same post.  It looks very much like a fait accompli.

<https://leanpub.com/preparing_for_perl7>

Per my original question, would you please go into more detail on why 
perl5-porters was intentionally insulated from this decision?

Could you also clarify why you felt it necessary to mislead the list 
about the existence of these plans in the post I linked?

<http://nntp.perl.org/group/perl.perl5.porters/257448>

>Everyone that was involved with this was in a shared file and viewable 
>by everyone else. It was clear who was involved.

Well, now that the changes the group intends to make are public, would 
you tell *us* who was involved, and how they were selected?

-- 
Tom Ryder <https://sanctum.geek.nz/>
Maybe we can bring back the light.
0
perl5
6/28/2020 5:06:05 AM
On Sat, 27 Jun 2020 12:18:30 +0100
"Paul \"LeoNerd\" Evans" <leonerd@leonerd.org.uk> wrote:

> Plus a "use v7" at the top of a file will be a BIG HINT to things like
> Github syntax highlighting, vim/emacs/other editors and IDEs ... so
> many places, that they should pick syntax highlighting relevant to
> Perl 7, not Perl 5.

Also to perltidy/perlcritic/etc...

Right now perltidy makes a huge mess of interesting syntax modules,
such as Syntax::Keyword::Try, because it doesn't realise the trailing
";" is not required on try/catch syntax.

perltidy's output looks something like

  sub f {
    try {
      A();
    catch {
      B();
    } return "result";
  }

Oops. Wrong. Should be

    ...
    catch {
      B();
    }
    return "result";


If `try` syntax becomes default - probably not in 7 but maybe in 8 -
then how is perltidy going to know how to properly format and indent
this, and all the other exciting syntax we hope to have in place by 8?

-- 
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk      |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/
0
leonerd
6/28/2020 7:38:33 AM

> On Jun 28, 2020, at 2:38 AM, Paul LeoNerd Evans =
<leonerd@leonerd.org.uk> wrote:
>=20
> If `try` syntax becomes default - probably not in 7 but maybe in 8 -
> then how is perltidy going to know how to properly format and indent
> this, and all the other exciting syntax we hope to have in place by 8?
>=20

Easily. They check $].
0
toddr
6/28/2020 8:39:52 AM

> On Jun 26, 2020, at 4:56 PM, Eric Wong <p5p@yhbt.net> wrote:
>=20
> Scripting languages like Perl, Python, Ruby, Tcl have
> significantly less room to evolve than compiled languages once
> they've reached critical mass.
>=20
> JavaScript is an exception.  For most users it's shipped with a
> complex browser which requires constant updates, anyways.  I
> can't say I know much about NodeJS, but I do hear about debacles
> (e.g. "leftpad") and stay clear of it.


You left out PHP which has added/removed stuff regularly as it has =
bumped versions. To my knowledge their user base has grown not shrunk as =
they made those changes.=20

Todd
0
toddr
6/28/2020 8:50:11 AM
>From: Todd Rinaldo=20
> On Sat, Jun 27, 2020 at 06:20:38PM +0300, Sawyer X wrote:
> >We (and this "we" includes you, Leon) know for a very long time now that
> p5p, the mailing list, is not a very practical place to discuss major cha=
nges.
>=20
> My objection is that the community didn't get a chance to discuss the
> changes at all, whether on perl5-porters or nay.  The changes were  annou=
nced
> after being decided by an apparently closed group---and were  already
> considered sufficiently finalised that a book has been released  by one o=
f the
> group about preparing for the changes, announced in the  very same post. =
 It
> looks very much like a fait accompli.
>=20
> <https://leanpub.com/preparing_for_perl7>
>=20
> Per my original question, would you
> please go into more detail on why=20
> perl5-porters was intentionally insulated
> from this decision?
>=20
> Could you also clarify why you felt it necessary to
> mislead the list=20
> about the existence of these plans in the post I linked?
>=20
> <http://nntp.perl.org/group/perl.perl5.porters/257448>
>=20
> >Everyone that was
> involved with this was in a shared file and viewable=20
> >by everyone else. It was
> clear who was involved.
>=20
> Well, now that the changes the group intends to make
> are public, would=20
> you tell *us* who was involved, and how they were selected?

+1
Me too
0
Vadim
6/28/2020 9:14:48 AM
On 26/6/20 21:42, Sawyer X wrote:

 > 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.

That ignores the fact that most of those old users are not interested in 
Perl anymore.

CPAN is full of code from authors that moved away from Perl long ago. 
Abandoned, but still perfectly working code!

Who is going to fix those modules? how long would it take? how many are 
just going to remain broken forever?

Even for still Perl loving authors, are you supposing all of them are 
going to take the burden of updating all their modules?

In my particular case, nowadays I barely use Perl, but still,
I keep maintaining my more important modules, mostly for attachment to 
them, the community and other romantic reasons but also because
they are mature and bugs are scarce and usually very easy to fix.

If you tell me now, that I would need to fix most (or just a good 
proportion) of them for Perl 7... well, I don't think I would run to do it.
0
sfandino
6/28/2020 11:50:28 AM
On 25/6/20 10:16, Dave Mitchell 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.
 >
 > 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;
 > ...

I just want to say that I have the same opinion as Dave.
0
sfandino
6/28/2020 11:52:16 AM
--0000000000008a1e6b05a923c61c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I would like to point out that the point is that older users are supposed
to shoulder the burden of the transition, so that newer users can join and
stay long enough to become older users.

On Sun, Jun 28, 2020 at 2:52 PM Salvador Fandi=C3=B1o <sfandino@gmail.com> =
wrote:

> On 25/6/20 10:16, Dave Mitchell 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 chang=
e.
>  >
>  > 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;
>  > ...
>
> I just want to say that I have the same opinion as Dave.
>

--0000000000008a1e6b05a923c61c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I would like to point out that the point is that older use=
rs are supposed to shoulder the burden of the transition, so that newer use=
rs can join and stay long enough to become older users.<br></div><br><div c=
lass=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Jun 28, =
2020 at 2:52 PM Salvador Fandi=C3=B1o &lt;<a href=3D"mailto:sfandino@gmail.=
com">sfandino@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,=
204);padding-left:1ex">On 25/6/20 10:16, Dave Mitchell wrote:<br>
=C2=A0&gt; On Wed, Jun 24, 2020 at 11:49:30PM +0300, Sawyer X wrote:<br>
=C2=A0&gt;&gt; * Major versions will be used for two purposes: 1. Turn on f=
eatures<br>
=C2=A0&gt;&gt; and pragmas by default, 2. Remove syntax from the language.<=
br>
=C2=A0&gt;<br>
=C2=A0&gt; I want to be on the record that I extremely strongly oppose this=
 change.<br>
=C2=A0&gt;<br>
=C2=A0&gt; I think if people want to use the new modern perl, they just put=
 this<br>
=C2=A0&gt; one simple line at the top of their code:<br>
=C2=A0&gt;<br>
=C2=A0&gt;=C2=A0 =C2=A0 =C2=A0 use v7;<br>
=C2=A0&gt; ...<br>
<br>
I just want to say that I have the same opinion as Dave.<br>
</blockquote></div>

--0000000000008a1e6b05a923c61c--
0
rabbiveesh
6/28/2020 12:06:31 PM
---1454121964-2098265702-1593345271=:16045
Content-Type: TEXT/PLAIN; format=flowed; charset=ISO-8859-15
Content-Transfer-Encoding: 8BIT
Content-ID: <alpine.DEB.1.00.2006281354401.16045@mail.mgm-net.de>

Not replying to any message of this thread in particular, but addressing
the default behavior of a "Perl 7", having read nearly all messages in
this thread.

IMHO the "use v7" vs. "use v5" issue cannot be adressed with a unified
perl, neither at compile nor run time. At this time, this decision can't
be made by p5p.

Instead, I would move the decision of whether having a future perl as v5
or v7 to the compilation of perl itself. So, a -Dv7 switch for Configure
would default to implicitly enable "use v7" during some time of future
perl development, and without that having a perl built which is perl5,
but still able to run as perl7 via "use v7".

Later on this could switch to defaulting to -Dv7 and only building for
perl5 as default via -Dv5.

This would avoid confusion and let vendors decide which flavour of perl
they want to have bundled with their OS. Those who build their own perl
binary can make their own decision.

Building with -Dv5 and -Dv7 would build both perl5 and perl7 binaries
defaulting either way and install perl5 as default, which could later be
changed defaulting to perl7.

just my 2�
0--gg-

-- 
_($_=" "x(1<<5)."?\n".q�/)Oo.  G�\        /
                                /\_�/(q    /
----------------------------  \__(m.====�.(_("always off the crowd"))."�
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}
---1454121964-2098265702-1593345271=:16045--
0
gm
6/28/2020 12:14:54 PM
>>>>> On Sun, 28 Jun 2020 03:39:52 -0500, Todd Rinaldo <toddr@cpanel.net> said:

 >> On Jun 28, 2020, at 2:38 AM, Paul LeoNerd Evans <leonerd@leonerd.org.uk> wrote:
 >> 
 >> If `try` syntax becomes default - probably not in 7 but maybe in 8 -
 >> then how is perltidy going to know how to properly format and indent
 >> this, and all the other exciting syntax we hope to have in place by 8?
 >> 

  > Easily. They check $].

Hi Todd,

this does not work. For example, see here is a line of perl code:

  print "Hello, Rinaldo";

So what is $] in this line and how do you find out? If you simply run
it, you make a decision, with which interpreter you start it. And hereby
you influence the outcome for $]. So: the value of $] is a result of
your decision, not something intrinsic to the code.

-- 
andreas
0
andreas
6/28/2020 12:33:15 PM
On Sun, 28 Jun 2020 14:33:15 +0200, Andreas Koenig <andreas.koenig.7os6VVqR@franz.ak.mind.de> wrote:

>>>>>> On Sun, 28 Jun 2020 03:39:52 -0500, Todd Rinaldo <toddr@cpanel.net> said:
>
>  >> On Jun 28, 2020, at 2:38 AM, Paul LeoNerd Evans <leonerd@leonerd.org.uk> wrote:
>  >>
>  >> If `try` syntax becomes default - probably not in 7 but maybe in 8 -
>  >> then how is perltidy going to know how to properly format and indent
>  >> this, and all the other exciting syntax we hope to have in place by 8?
>  >>
>
>   > Easily. They check $].
>
> Hi Todd,
>
> this does not work. For example, see here is a line of perl code:
>
>   print "Hello, Rinaldo";
>
> So what is $] in this line and how do you find out? If you simply run
> it, you make a decision, with which interpreter you start it. And hereby
> you influence the outcome for $]. So: the value of $] is a result of
> your decision, not something intrinsic to the code.

As maintainer of the perl document parsing module PPI this is also a massive concern for me.

It needs to load and interpret perl from many sources, including stuff not intended to run on the current interpreter.

The version of the current perl interpreter does literally nothing to help PPI process a script intended to run on a server somewhere else.

Having *more* wide-spread perl version requirements in perl modules and scripts would be an absolute godsend to PPI and frankly ...

.... i hesitate to express this, but ...

I'm livid that PPI is going to be denied this functionality improvement just to save people from typing 7 letters.

There's also the absolutely brain-bending reality that under perl BELOW v7, no version means "oldest perl feature set", while under v7 no version means "newest feature set" ... and being unable to know under which version the code is targeted to run, how is PPI going to solve this? How's it gonna decide how to parse an indirect-looking call?

https://i.imgur.com/Q8EvkXU.png

I'm going to have to have to implement two parsing modes parametrized by a version assumption passed into the constructor. All upstream users of PPI will have to do the same. Am i allowed to be angry about this? Can you imagine how i feel?

Also recommend talking to the Perl::Critic team.

Have a nice sunday y'all. :3

-- 
With regards,
Christian Walde
0
walde
6/28/2020 2:12:48 PM
On Sun, 28 Jun 2020 16:12:48 +0200, Christian Walde <walde.christian@gmail.com> wrote:

> On Sun, 28 Jun 2020 14:33:15 +0200, Andreas Koenig <andreas.koenig.7os6VVqR@franz.ak.mind.de> wrote:
>
>>>>>>> On Sun, 28 Jun 2020 03:39:52 -0500, Todd Rinaldo <toddr@cpanel.net> said:
>>
>>  >> On Jun 28, 2020, at 2:38 AM, Paul LeoNerd Evans <leonerd@leonerd.org.uk> wrote:
>>  >>
>>  >> If `try` syntax becomes default - probably not in 7 but maybe in 8 -
>>  >> then how is perltidy going to know how to properly format and indent
>>  >> this, and all the other exciting syntax we hope to have in place by 8?
>>  >>
>>
>>   > Easily. They check $].
>>
>> Hi Todd,
>>
>> this does not work. For example, see here is a line of perl code:
>>
>>   print "Hello, Rinaldo";
>>
>> So what is $] in this line and how do you find out? If you simply run
>> it, you make a decision, with which interpreter you start it. And hereby
>> you influence the outcome for $]. So: the value of $] is a result of
>> your decision, not something intrinsic to the code.
>
> As maintainer of the perl document parsing module PPI this is also a massive concern for me.
>
> It needs to load and interpret perl from many sources, including stuff not intended to run on the current interpreter.
>
> The version of the current perl interpreter does literally nothing to help PPI process a script intended to run on a server somewhere else.
>
> Having *more* wide-spread perl version requirements in perl modules and scripts would be an absolute godsend to PPI and frankly ...
>
> ... i hesitate to express this, but ...
>
> I'm livid that PPI is going to be denied this functionality improvement just to save people from typing 7 letters.
>
> There's also the absolutely brain-bending reality that under perl BELOW v7, no version means "oldest perl feature set", while under v7 no version means "newest feature set" ... and being unable to know under which version the code is targeted to run, how is PPI going to solve this? How's it gonna decide how to parse an indirect-looking call?
>
> https://i.imgur.com/Q8EvkXU.png
>
> I'm going to have to have to implement two parsing modes parametrized by a version assumption passed into the constructor. All upstream users of PPI will have to do the same. Am i allowed to be angry about this? Can you imagine how i feel?
>
> Also recommend talking to the Perl::Critic team.
>
> Have a nice sunday y'all. :3

To be unmistakably clear here, this is my concern:

     use PPI;
     use PPI::Dumper;

     my $perl = 'sub foo ($left, $right) {}';

     PPI::Dumper->new(PPI::Document->new(\$perl))->print;

     __END__

     PPI::Document
       PPI::Statement::Sub
         PPI::Token::Word    'sub'
         PPI::Token::Whitespace      ' '
         PPI::Token::Word    'foo'
         PPI::Token::Whitespace      ' '
         PPI::Token::Prototype       '($left, $right)'
         PPI::Token::Whitespace      ' '
         PPI::Structure::Block       { ... }

-- 
With regards,
Christian Walde
0
walde
6/28/2020 2:57:25 PM
On Fri, 26 Jun 2020 20:57:39 +0200, John Lightsey <john@nixnuts.net> wrote:

> I'd love to see Perl 8 fix [...] Windows support.

2 things here:

1. Please don't phrase it in a way that implies Perl doesn't support windows. I've been developing Perl on windows for over a decade and it works.

2. Out of curiosity, what specific points do you care about here?

-- 
With regards,
Christian Walde
0
walde
6/28/2020 5:23:45 PM
Hello all,

I am speaking as a user who was thrilled by the announcement of Perl 7. I'm=
 not a core developer, nor do I maintain a lot of CPAN modules. For this e-=
mail just think of me as a random Perl developer who has seen the announcem=
ent.

I was absolutely stoked when you (Sawyer) made the announcement. I send out=
 a few messages to co-workers during your long build to the actual announce=
ment and was very pleased when you finally said those words: Perl 7.

Major version bumps make it possible to break backward compatibility and th=
us allowing new things in favor of the old. Perl 5 is still going to be sup=
ported for a lot of years. For all the code that is out there and those who=
 wants to rely on Perl 5, they can use that specific version. I'm looking f=
orward to be able to use the new shiny syntax stuff that isn't available in=
 older versions of Perl 5. Perl 7 allows forward progression by ditching th=
e mistakes of the past. It allows me as a user to pick a version of Perl th=
at suits my needs. Need Perl 5 for that, great let's use p5. Want to write =
more modern Perl, p7 or up. I love it. And for me a big reason why there ar=
e major versions.

Most of the comments in this thread talk about backward compatibility with =
p5. I think this viewpoint is exactly what is addressed in the build up to =
the announcement. Newer stuff cannot be implemented because of the old stuf=
f. We need to make a break somewhere. We are in this current position becau=
se the progression of Perl 5 has been hindered by the development of Perl 6=
/Raku (please don't see this as a bash against Perl6/Raku). IMHO it just cr=
eated a situation where the let's not break older code in p5 became some so=
rt of holy bible. Which is good, because that became the goal of p5, as it =
was in maintenance mode. Now with p7 we can change that goal. Implement new=
 and shiny things, break with the old.

When I fire up the latest and greatest Perl I want to use all the (new) fea=
tures by default and not having to enable them via `use feature`. It should=
 become the default. Perl 7 allows that. I love the idea that `use feature`=
 now becomes similar to `use experimental` (maybe not fully, but from a hig=
h level it seems this way).

I see comments about CPAN modules. CPAN is broken in a way. Old modules rec=
eive no security updates. When and if they are broken they aren't updated. =
Getting permission to take over the module is a painful endeavor. This move=
 will also shake the tree a bit and we will see which modules break and whi=
ch don't. Which ones are getting forked or get new maintainers to be used i=
n Perl 7 and above and which will not.

Moving to Perl 7 within a year might be tricky if I read everything on the =
list. We as a community need to decide:

1) What the current and future goal is of p5.
2) What the goal is of p7 (and up).
3) If we are going to stay backward compatible for the next decade(s) with =
newer perl versions (7 and up).
4) If we want forward progression in favor of keeping 20 year old perl 5 co=
de alive.
5) If CPAN needs to support unsupported perl versions.
6) Does p5 support p4 and if so (I don't know. And if it doesn't, why would=
 we want p7 to support p5?) do we want p7 to support p5 and lower?
7) Do we want to maintain two different version if p5 and p7 cannot reach a=
greement on backward compatibility?

Once these questions have been answered and a consensus has been found we c=
an move forward.

A few questions:
* Is there a public roadmap of what p7 will bring us and what we can expect=
 from it?
* Where can we file feature requests for p7?

Cheers,
Wesley
0
perl5
6/28/2020 6:58:02 PM
On 6/28/20 1:23 PM, Christian Walde wrote:
> On Fri, 26 Jun 2020 20:57:39 +0200, John Lightsey <john@nixnuts.net> wrote:
> 
>> I'd love to see Perl 8 fix [...] Windows support.
> 
> 2 things here:
> 
> 1. Please don't phrase it in a way that implies Perl doesn't support 
> windows. I've been developing Perl on windows for over a decade and it 
> works.
> 

Unfortunately, the data available to us suggests we have problems 
maintaining Perl on Windows in optimal condition.

Go to http://perl5.test-smoke.org/search and plug in "MSWin32" to the 
OSname drop-down.  Observe a long list of FAILs.

Now, I grant you that it only takes one unit test failure in one test 
file to grade the whole smoke-test run FAIL.  Nonetheless, we do a good 
job of getting PASSes on Linux and at least 3 of the BSDs.

We need smoke-test reports preferably (a) from recent Windows releases 
for the business environment; and (b) from testers skilled enough in, 
and dedicated enough to, Windows to be able to diagnose failures and 
work with us to fix them.

Thank you very much.
Jim Keenan
0
jkeenan
6/28/2020 7:01:54 PM
--0000000000001a5f0705a929b489
Content-Type: text/plain; charset="UTF-8"

On Sun, Jun 28, 2020 at 3:04 PM Wesley Schwengle via perl5-porters <
perl5-porters@perl.org> wrote:

> Major version bumps make it possible to break backward compatibility and
> thus allowing new things in favor of the old. Perl 5 is still going to be
> supported for a lot of years. For all the code that is out there and those
> who wants to rely on Perl 5, they can use that specific version. I'm
> looking forward to be able to use the new shiny syntax stuff that isn't
> available in older versions of Perl 5. Perl 7 allows forward progression by
> ditching the mistakes of the past. It allows me as a user to pick a version
> of Perl that suits my needs. Need Perl 5 for that, great let's use p5. Want
> to write more modern Perl, p7 or up. I love it. And for me a big reason why
> there are major versions.
>
> Most of the comments in this thread talk about backward compatibility with
> p5. I think this viewpoint is exactly what is addressed in the build up to
> the announcement. Newer stuff cannot be implemented because of the old
> stuff. We need to make a break somewhere. We are in this current position
> because the progression of Perl 5 has been hindered by the development of
> Perl 6/Raku (please don't see this as a bash against Perl6/Raku). IMHO it
> just created a situation where the let's not break older code in p5 became
> some sort of holy bible. Which is good, because that became the goal of p5,
> as it was in maintenance mode. Now with p7 we can change that goal.
> Implement new and shiny things, break with the old.
>
> When I fire up the latest and greatest Perl I want to use all the (new)
> features by default and not having to enable them via `use feature`. It
> should become the default. Perl 7 allows that. I love the idea that `use
> feature` now becomes similar to `use experimental` (maybe not fully, but
> from a high level it seems this way).
>

This is a false choice. We can and have added and removed features in each
release of Perl. Changing the defaults does not affect that ability, nor
has any streamlining of feature removal been proposed as of yet, nor
explanation of how such a change in policy would necessitate changing
defaults.

A new major version indeed has all of the benefits you are extolling, I
think it's a wonderful opportunity and long overdue. Changing the defaults
doesn't add anything to this benefit and adds a lot of problems to work
around, like your whole list of considerations.

-Dan

--0000000000001a5f0705a929b489
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Sun, Jun 28, 2020 at 3:04 PM Wesley Sc=
hwengle via perl5-porters &lt;<a href=3D"mailto:perl5-porters@perl.org">per=
l5-porters@perl.org</a>&gt; wrote:</div><div class=3D"gmail_quote"><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
 solid rgb(204,204,204);padding-left:1ex">
Major version bumps make it possible to break backward compatibility and th=
us allowing new things in favor of the old. Perl 5 is still going to be sup=
ported for a lot of years. For all the code that is out there and those who=
 wants to rely on Perl 5, they can use that specific version. I&#39;m looki=
ng forward to be able to use the new shiny syntax stuff that isn&#39;t avai=
lable in older versions of Perl 5. Perl 7 allows forward progression by dit=
ching the mistakes of the past. It allows me as a user to pick a version of=
 Perl that suits my needs. Need Perl 5 for that, great let&#39;s use p5. Wa=
nt to write more modern Perl, p7 or up. I love it. And for me a big reason =
why there are major versions.<br>
<br>
Most of the comments in this thread talk about backward compatibility with =
p5. I think this viewpoint is exactly what is addressed in the build up to =
the announcement. Newer stuff cannot be implemented because of the old stuf=
f. We need to make a break somewhere. We are in this current position becau=
se the progression of Perl 5 has been hindered by the development of Perl 6=
/Raku (please don&#39;t see this as a bash against Perl6/Raku). IMHO it jus=
t created a situation where the let&#39;s not break older code in p5 became=
 some sort of holy bible. Which is good, because that became the goal of p5=
, as it was in maintenance mode. Now with p7 we can change that goal. Imple=
ment new and shiny things, break with the old.<br>
<br>
When I fire up the latest and greatest Perl I want to use all the (new) fea=
tures by default and not having to enable them via `use feature`. It should=
 become the default. Perl 7 allows that. I love the idea that `use feature`=
 now becomes similar to `use experimental` (maybe not fully, but from a hig=
h level it seems this way).<br></blockquote><div><br></div><div>This is a f=
alse choice. We can and have added and removed features in each release of =
Perl. Changing the defaults does not affect that ability, nor has any strea=
mlining of feature removal been proposed as of yet, nor explanation of how =
such a change in policy would necessitate changing defaults.</div><div><br>=
</div><div>A new major version indeed has all of the benefits you are extol=
ling, I think it&#39;s a wonderful opportunity and long overdue. Changing t=
he defaults doesn&#39;t add anything to this benefit and adds a lot of prob=
lems to work around, like your whole list of considerations.</div><div><br>=
</div><div>-Dan</div></div></div>

--0000000000001a5f0705a929b489--
0
grinnz
6/28/2020 7:10:39 PM
Todd Rinaldo <toddr@cpanel.net> wrote:
> > On Jun 26, 2020, at 4:56 PM, Eric Wong <p5p@yhbt.net> wrote:
> > 
> > Scripting languages like Perl, Python, Ruby, Tcl have
> > significantly less room to evolve than compiled languages once
> > they've reached critical mass.
> > 
> > JavaScript is an exception.  For most users it's shipped with a
> > complex browser which requires constant updates, anyways.  I
> > can't say I know much about NodeJS, but I do hear about debacles
> > (e.g. "leftpad") and stay clear of it.
> 
> You left out PHP which has added/removed stuff regularly as it
> has bumped versions. To my knowledge their user base has grown
> not shrunk as they made those changes. 

True, I don't know much about PHP, but my limited understanding
is that it's far less used for tooling (build systems, packaging
systems, CLI tools) than the others.  It's certainly not part of
default OS installs the way Perl and Python tend to be.

Honestly, I think Perl could appeal to newbies (and maybe
returning old schoolers) who've been bitten by the Python 2/3
mess.
0
p5p
6/28/2020 7:13:47 PM
On Sun, Jun 28, 2020 at 7:24 PM Christian Walde
<walde.christian@gmail.com> wrote:
>
> On Fri, 26 Jun 2020 20:57:39 +0200, John Lightsey <john@nixnuts.net> wrote:
>
> > I'd love to see Perl 8 fix [...] Windows support.
>
> 2 things here:
>
> 1. Please don't phrase it in a way that implies Perl doesn't support windows. I've been developing Perl on windows for over a decade and it works.
>
> 2. Out of curiosity, what specific points do you care about here?

Unicode filesystem support?

Leon
0
fawaka
6/28/2020 9:20:26 PM
On Sun, 28 Jun 2020 21:01:54 +0200, James E Keenan <jkeenan@pobox.com> wrote:

> On 6/28/20 1:23 PM, Christian Walde wrote:
>> On Fri, 26 Jun 2020 20:57:39 +0200, John Lightsey <john@nixnuts.net> wrote:
>>
>>> I'd love to see Perl 8 fix [...] Windows support.
>>
>> 2 things here:
>>
>> 1. Please don't phrase it in a way that implies Perl doesn't support
>> windows. I've been developing Perl on windows for over a decade and it
>> works.
>>
>
> Unfortunately, the data available to us suggests we have problems
> maintaining Perl on Windows in optimal condition.
>
> Go to http://perl5.test-smoke.org/search and plug in "MSWin32" to the
> OSname drop-down.  Observe a long list of FAILs.
>
> Now, I grant you that it only takes one unit test failure in one test
> file to grade the whole smoke-test run FAIL.  Nonetheless, we do a good
> job of getting PASSes on Linux and at least 3 of the BSDs.
>
> We need smoke-test reports preferably (a) from recent Windows releases
> for the business environment; and (b) from testers skilled enough in,
> and dedicated enough to, Windows to be able to diagnose failures and
> work with us to fix them.
>
> Thank you very much.
> Jim Keenan
>

Alright, i reenabled my smoker. Please look out for its first report in a few hours. :)

I think last time i had it running it was generating a bunch of PASSes and everything seemed fine and nobody ever contacted me about it even if stuff switched to red.

http://perl5.test-smoke.org/search?andnot_arch=0&selected_arch=&andnotsel_arch=0&report_arch=&selected_osnm=MSWin32&andnotsel_osnm=0&report_osnm=MSWin32&selected_host=DigitizedSqueak&andnotsel_host=0&report_host=DigitizedSqueak&andnot_osvs=0&selected_osvs=&andnotsel_osvs=0&report_osvs=&andnot_comp=0&selected_comp=&andnotsel_comp=0&config_comp=&selected_perl=all&andnot_cver=0&selected_cver=&andnotsel_cver=0&config_cver=&page=5

Here's the last PASS that machine sent: http://perl5.test-smoke.org/report/91097
Followed by the first FAIL after that: http://perl5.test-smoke.org/report/91170
And that machine's last fail before it went offline a while: http://perl5.test-smoke.org/report/97253

You're correct that in both of these only a single test was at fault, and particularly in the latter one, not even one that indicates core is broken.

In fact, it appears that Net::Ping's port test is just plain flaky on windows: http://matrix.cpantesters.org/?dist=Net-Ping%202.73 and in fact, the specific test causing the issue is also TODO'd on hpux|os390|freebsd, so it's probably more to do with the dist itself, and not anything with Windows.

I've created a pull request for that purpose here: https://github.com/rurban/Net-Ping/pull/20

Otherwise, how can i instruct my smoker to skip specific test files?

Also, you could just commit the proposed change there to blead for now.

That said, i still contend that the phrasing "fix windows support" is misapplied, as Perl the executable handily supports windows and doesn't need fixing but improvement.

-- 
With regards,
Christian Walde
0
walde
6/28/2020 9:45:03 PM
On Sun, 28 Jun 2020 23:20:26 +0200, Leon Timmermans <fawaka@gmail.com> wrote:

> On Sun, Jun 28, 2020 at 7:24 PM Christian Walde
> <walde.christian@gmail.com> wrote:
>>
>> On Fri, 26 Jun 2020 20:57:39 +0200, John Lightsey <john@nixnuts.net> wrote:
>>
>> > I'd love to see Perl 8 fix [...] Windows support.
>>
>> 2 things here:
>>
>> 1. Please don't phrase it in a way that implies Perl doesn't support windows. I've been developing Perl on windows for over a decade and it works.
>>
>> 2. Out of curiosity, what specific points do you care about here?
>
> Unicode filesystem support?

It would be a nice improvement to have that out of the box instead of needing to use CPAN modules for it. Good reminder.

-- 
With regards,
Christian Walde
0
walde
6/28/2020 9:52:02 PM
On 28/6/20 23:20, Leon Timmermans wrote:
 > On Sun, Jun 28, 2020 at 7:24 PM Christian Walde
 > <walde.christian@gmail.com> wrote:
 >>
 >> On Fri, 26 Jun 2020 20:57:39 +0200, John Lightsey <john@nixnuts.net> 
wrote:
 >>
 >>> I'd love to see Perl 8 fix [...] Windows support.
 >>
 >> 2 things here:
 >>
 >> 1. Please don't phrase it in a way that implies Perl doesn't support 
windows. I've been developing Perl on windows for over a decade and it 
works.
 >>
 >> 2. Out of curiosity, what specific points do you care about here?
 >
 > Unicode filesystem support?

+1

Though, that may be more visible in Windows but the problem exists also 
under other operating systems. On file system calls Perl just passes to 
the OS whatever is in the pv slot without looking at the encoding:

   $ perl
   use utf8;
   my $a = "araña";
   my $b = "ara\xf1a";
   open F, ">$a";
   open F, ">$b";
   print($a==$b, "\n")
   1
   $ echo ara*
   ara�a araña
0
sfandino
6/28/2020 9:52:03 PM
--000000000000a44f8805a92c1120
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, Jun 28, 2020 at 5:52 PM Salvador Fandi=C3=B1o <sfandino@gmail.com> =
wrote:

> On 28/6/20 23:20, Leon Timmermans wrote:
>  > On Sun, Jun 28, 2020 at 7:24 PM Christian Walde
>  > <walde.christian@gmail.com> wrote:
>  >>
>  >> On Fri, 26 Jun 2020 20:57:39 +0200, John Lightsey <john@nixnuts.net>
> wrote:
>  >>
>  >>> I'd love to see Perl 8 fix [...] Windows support.
>  >>
>  >> 2 things here:
>  >>
>  >> 1. Please don't phrase it in a way that implies Perl doesn't support
> windows. I've been developing Perl on windows for over a decade and it
> works.
>  >>
>  >> 2. Out of curiosity, what specific points do you care about here?
>  >
>  > Unicode filesystem support?
>
> +1
>
> Though, that may be more visible in Windows but the problem exists also
> under other operating systems. On file system calls Perl just passes to
> the OS whatever is in the pv slot without looking at the encoding:
>
>    $ perl
>    use utf8;
>    my $a =3D "ara=C3=B1a";
>    my $b =3D "ara\xf1a";
>    open F, ">$a";
>    open F, ">$b";
>    print($a=3D=3D$b, "\n")
>    1
>    $ echo ara*
>    ara=EF=BF=BDa ara=C3=B1a
>

This is a well established bug with filename handling in Perl, see
https://github.com/Perl/perl5/issues/9674 and
https://github.com/Perl/perl5/issues/10550.

-Dan

--000000000000a44f8805a92c1120
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Sun, Jun 28, 2020 at 5:52 PM Salvador =
Fandi=C3=B1o &lt;<a href=3D"mailto:sfandino@gmail.com">sfandino@gmail.com</=
a>&gt; wrote:<br></div><div class=3D"gmail_quote"><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex">On 28/6/20 23:20, Leon Timmermans wrote:<br>
=C2=A0&gt; On Sun, Jun 28, 2020 at 7:24 PM Christian Walde<br>
=C2=A0&gt; &lt;<a href=3D"mailto:walde.christian@gmail.com" target=3D"_blan=
k">walde.christian@gmail.com</a>&gt; wrote:<br>
=C2=A0&gt;&gt;<br>
=C2=A0&gt;&gt; On Fri, 26 Jun 2020 20:57:39 +0200, John Lightsey &lt;<a hre=
f=3D"mailto:john@nixnuts.net" target=3D"_blank">john@nixnuts.net</a>&gt; <b=
r>
wrote:<br>
=C2=A0&gt;&gt;<br>
=C2=A0&gt;&gt;&gt; I&#39;d love to see Perl 8 fix [...] Windows support.<br=
>
=C2=A0&gt;&gt;<br>
=C2=A0&gt;&gt; 2 things here:<br>
=C2=A0&gt;&gt;<br>
=C2=A0&gt;&gt; 1. Please don&#39;t phrase it in a way that implies Perl doe=
sn&#39;t support <br>
windows. I&#39;ve been developing Perl on windows for over a decade and it =
<br>
works.<br>
=C2=A0&gt;&gt;<br>
=C2=A0&gt;&gt; 2. Out of curiosity, what specific points do you care about =
here?<br>
=C2=A0&gt;<br>
=C2=A0&gt; Unicode filesystem support?<br>
<br>
+1<br>
<br>
Though, that may be more visible in Windows but the problem exists also <br=
>
under other operating systems. On file system calls Perl just passes to <br=
>
the OS whatever is in the pv slot without looking at the encoding:<br>
<br>
=C2=A0 =C2=A0$ perl<br>
=C2=A0 =C2=A0use utf8;<br>
=C2=A0 =C2=A0my $a =3D &quot;ara=C3=B1a&quot;;<br>
=C2=A0 =C2=A0my $b =3D &quot;ara\xf1a&quot;;<br>
=C2=A0 =C2=A0open F, &quot;&gt;$a&quot;;<br>
=C2=A0 =C2=A0open F, &quot;&gt;$b&quot;;<br>
=C2=A0 =C2=A0print($a=3D=3D$b, &quot;\n&quot;)<br>
=C2=A0 =C2=A01<br>
=C2=A0 =C2=A0$ echo ara*<br>
=C2=A0 =C2=A0ara=EF=BF=BDa ara=C3=B1a<br></blockquote><div><br></div><div>T=
his is a well established bug with filename handling in Perl, see=C2=A0<a h=
ref=3D"https://github.com/Perl/perl5/issues/9674">https://github.com/Perl/p=
erl5/issues/9674</a>=C2=A0and=C2=A0<a href=3D"https://github.com/Perl/perl5=
/issues/10550">https://github.com/Perl/perl5/issues/10550</a>.</div><div><b=
r></div><div>-Dan=C2=A0</div></div></div>

--000000000000a44f8805a92c1120--
0
grinnz
6/28/2020 9:59:58 PM

> On Jun 28, 2020, at 17:53, Salvador Fandi=C3=B1o <sfandino@gmail.com> wrot=
e:
>=20
> =EF=BB=BFOn 28/6/20 23:20, Leon Timmermans wrote:
> > On Sun, Jun 28, 2020 at 7:24 PM Christian Walde
> > <walde.christian@gmail.com> wrote:
> >>
> >> On Fri, 26 Jun 2020 20:57:39 +0200, John Lightsey <john@nixnuts.net> wr=
ote:
> >>
> >>> I'd love to see Perl 8 fix [...] Windows support.
> >>
> >> 2 things here:
> >>
> >> 1. Please don't phrase it in a way that implies Perl doesn't support wi=
ndows. I've been developing Perl on windows for over a decade and it works.
> >>
> >> 2. Out of curiosity, what specific points do you care about here?
> >
> > Unicode filesystem support?
>=20
> +1
>=20
> Though, that may be more visible in Windows but the problem exists also un=
der other operating systems. On file system calls Perl just passes to the OS=
 whatever is in the pv slot without looking at the encoding:

But *can* Perl intelligently do anything with the encoding? I thought one of=
 the string=E2=80=99s internal encoding has no bearing on anything outside i=
nterpreter internals; thus, the Perl code would somehow have to indicate whi=
ch strings are which encoding.

-F=
0
felipe
6/28/2020 10:02:21 PM
--00000000000092c1c205a92c22af
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, Jun 28, 2020 at 6:02 PM Felipe Gasper <felipe@felipegasper.com>
wrote:

>
>
> > On Jun 28, 2020, at 17:53, Salvador Fandi=C3=B1o <sfandino@gmail.com> w=
rote:
> >
> > =EF=BB=BFOn 28/6/20 23:20, Leon Timmermans wrote:
> > > On Sun, Jun 28, 2020 at 7:24 PM Christian Walde
> > > <walde.christian@gmail.com> wrote:
> > >>
> > >> On Fri, 26 Jun 2020 20:57:39 +0200, John Lightsey <john@nixnuts.net>
> wrote:
> > >>
> > >>> I'd love to see Perl 8 fix [...] Windows support.
> > >>
> > >> 2 things here:
> > >>
> > >> 1. Please don't phrase it in a way that implies Perl doesn't support
> windows. I've been developing Perl on windows for over a decade and it
> works.
> > >>
> > >> 2. Out of curiosity, what specific points do you care about here?
> > >
> > > Unicode filesystem support?
> >
> > +1
> >
> > Though, that may be more visible in Windows but the problem exists also
> under other operating systems. On file system calls Perl just passes to t=
he
> OS whatever is in the pv slot without looking at the encoding:
>
> But *can* Perl intelligently do anything with the encoding? I thought one
> of the string=E2=80=99s internal encoding has no bearing on anything outs=
ide
> interpreter internals; thus, the Perl code would somehow have to indicate
> which strings are which encoding.


No, but it can at least be consistent with how strings work in the rest of
Perl since 5.8 - that two strings that compare equal shouldn't open
different files because of how they're stored, and vice versa.

-Dan

--00000000000092c1c205a92c22af
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Sun, Jun 28, 2020 at 6:02 PM Felipe Ga=
sper &lt;<a href=3D"mailto:felipe@felipegasper.com">felipe@felipegasper.com=
</a>&gt; wrote:<br></div><div class=3D"gmail_quote"><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,=
204,204);padding-left:1ex"><br>
<br>
&gt; On Jun 28, 2020, at 17:53, Salvador Fandi=C3=B1o &lt;<a href=3D"mailto=
:sfandino@gmail.com" target=3D"_blank">sfandino@gmail.com</a>&gt; wrote:<br=
>
&gt; <br>
&gt; =EF=BB=BFOn 28/6/20 23:20, Leon Timmermans wrote:<br>
&gt; &gt; On Sun, Jun 28, 2020 at 7:24 PM Christian Walde<br>
&gt; &gt; &lt;<a href=3D"mailto:walde.christian@gmail.com" target=3D"_blank=
">walde.christian@gmail.com</a>&gt; wrote:<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; On Fri, 26 Jun 2020 20:57:39 +0200, John Lightsey &lt;<a href=
=3D"mailto:john@nixnuts.net" target=3D"_blank">john@nixnuts.net</a>&gt; wro=
te:<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;&gt; I&#39;d love to see Perl 8 fix [...] Windows support.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; 2 things here:<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; 1. Please don&#39;t phrase it in a way that implies Perl does=
n&#39;t support windows. I&#39;ve been developing Perl on windows for over =
a decade and it works.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; 2. Out of curiosity, what specific points do you care about h=
ere?<br>
&gt; &gt;<br>
&gt; &gt; Unicode filesystem support?<br>
&gt; <br>
&gt; +1<br>
&gt; <br>
&gt; Though, that may be more visible in Windows but the problem exists als=
o under other operating systems. On file system calls Perl just passes to t=
he OS whatever is in the pv slot without looking at the encoding:<br>
<br>
But *can* Perl intelligently do anything with the encoding? I thought one o=
f the string=E2=80=99s internal encoding has no bearing on anything outside=
 interpreter internals; thus, the Perl code would somehow have to indicate =
which strings are which encoding.</blockquote><div><br></div><div>No, but i=
t can at least be consistent with how strings work in the rest of Perl sinc=
e 5.8 - that two strings that compare equal shouldn&#39;t open different fi=
les because of how they&#39;re stored, and vice versa.</div><div><br></div>=
<div>-Dan=C2=A0</div></div></div>

--00000000000092c1c205a92c22af--
0
grinnz
6/28/2020 10:04:42 PM
On Sun, Jun 28, 2020 at 11:52 PM Salvador Fandi=C3=B1o <sfandino@gmail.com>=
 wrote:
> Though, that may be more visible in Windows but the problem exists also
> under other operating systems. On file system calls Perl just passes to
> the OS whatever is in the pv slot without looking at the encoding:
>
>    $ perl
>    use utf8;
>    my $a =3D "ara=C3=B1a";
>    my $b =3D "ara\xf1a";
>    open F, ">$a";
>    open F, ">$b";
>    print($a=3D=3D$b, "\n")
>    1
>    $ echo ara*
>    ara=EF=BF=BDa ara=C3=B1a

The hardest thing here AFAICT is to get to a portable abstraction so
you can write code that works well on both linux and windows.

Both are currently problematic in very different ways.

Leon
0
fawaka
6/28/2020 10:28:28 PM
Relying on short (dos 8,3) filenames is a huge problem still. Fixing
that will go a long way to fixing the remaining issues on Windows.
Using full paths would be exceedingly helpful. My life would be so
much easier in maintaining some of the dists I help out with.

On Sun, Jun 28, 2020 at 6:29 PM Leon Timmermans <fawaka@gmail.com> wrote:
>
> On Sun, Jun 28, 2020 at 11:52 PM Salvador Fandi=C3=B1o <sfandino@gmail.co=
m> wrote:
> > Though, that may be more visible in Windows but the problem exists also
> > under other operating systems. On file system calls Perl just passes to
> > the OS whatever is in the pv slot without looking at the encoding:
> >
> >    $ perl
> >    use utf8;
> >    my $a =3D "ara=C3=B1a";
> >    my $b =3D "ara\xf1a";
> >    open F, ">$a";
> >    open F, ">$b";
> >    print($a=3D=3D$b, "\n")
> >    1
> >    $ echo ara*
> >    ara=EF=BF=BDa ara=C3=B1a
>
> The hardest thing here AFAICT is to get to a portable abstraction so
> you can write code that works well on both linux and windows.
>
> Both are currently problematic in very different ways.
>
> Leon
0
cwhitener
6/28/2020 11:25:01 PM
--000000000000ca63cf05a92df8cb
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

While it's fun to get into the weeds, I am convinced that any technical
problem can be solved by the fine people on this list. I have faith in the
Perl community's creativity and resourcefulness. That means that the more
important thing is to make the decision. Sawyer has done this, and has
explained why he made those design choices in his talk.

Now we have the fun of implementing a practical solution.

Up to this point the discussion has focused on trying to solve technical
issues at the language level. Must we? Can't we solve some of these with
tooling?

As an example, consider a distribution written targeting Perl5 (which is
all of CPAN at the moment). When you try to install it under Perl7, EU::MM
or M::B know that you are installing it under v7. With a little metadata
(and sane defaults) these tools can be told the distribution targets Perl
5. In that case they can do all kinds of stuff for us. Perhaps they can add
shebang lines to the top of every .pm and .pl file with a command-line
switch indicating Perl 5. Perhaps they can add the "use compat::perl5=E2=80=
=9D line
(however it is spelled) at the top of each module/script. Perhaps all Perl
5 modules are installed with the suffix .pm5, and Perl 7 is taught to look
for those alongside .pm and .pmc. Perhaps all files with a .pl5 extension
are parsed with Perl 5 compatibility, and the tooling automatically
switches .pl to .pl5. And finally, the tooling can be more conservative
than the language when it comes to defaults. No targeted Major version?
Tooling can assume Perl 5 until 2040 for all I care.

In short, I don't believe that CPAN-compatibility needs to be solved at the
language level. Giving new users all the shiny bits out of the box *for*
*free* is really appealing to me. This is do important to me that I will
step up and help with the tooling if that is the route that makes the most
sense, and I bet I'm not alone.

David

On Sun, Jun 28, 2020, 3:13 PM Eric Wong <p5p@yhbt.net> wrote:

> Todd Rinaldo <toddr@cpanel.net> wrote:
> > > On Jun 26, 2020, at 4:56 PM, Eric Wong <p5p@yhbt.net> wrote:
> > >
> > > Scripting languages like Perl, Python, Ruby, Tcl have
> > > significantly less room to evolve than compiled languages once
> > > they've reached critical mass.
> > >
> > > JavaScript is an exception.  For most users it's shipped with a
> > > complex browser which requires constant updates, anyways.  I
> > > can't say I know much about NodeJS, but I do hear about debacles
> > > (e.g. "leftpad") and stay clear of it.
> >
> > You left out PHP which has added/removed stuff regularly as it
> > has bumped versions. To my knowledge their user base has grown
> > not shrunk as they made those changes.
>
> True, I don't know much about PHP, but my limited understanding
> is that it's far less used for tooling (build systems, packaging
> systems, CLI tools) than the others.  It's certainly not part of
> default OS installs the way Perl and Python tend to be.
>
> Honestly, I think Perl could appeal to newbies (and maybe
> returning old schoolers) who've been bitten by the Python 2/3
> mess.
>

--000000000000ca63cf05a92df8cb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">While it&#39;s fun to get into the weeds, I am convinced =
that any technical problem can be solved by the fine people on this list. I=
 have faith in the Perl community&#39;s creativity and resourcefulness. Tha=
t means that the more important thing is to make the decision. Sawyer has d=
one this, and has explained why he made those design choices in his talk.<d=
iv dir=3D"auto"><br></div><div dir=3D"auto">Now we have the fun of implemen=
ting a practical solution.</div><div dir=3D"auto"><br></div><div dir=3D"aut=
o">Up to this point the discussion has focused on trying to solve technical=
 issues at the language level. Must we? Can&#39;t we solve some of these wi=
th tooling?</div><div dir=3D"auto"><br></div><div dir=3D"auto">As an exampl=
e, consider a distribution written targeting Perl5 (which is all of CPAN at=
 the moment). When you try to install it under Perl7, EU::MM or M::B know t=
hat you are installing it under v7. With a little metadata (and sane defaul=
ts) these tools can be told the distribution targets Perl 5. In that case t=
hey can do all kinds of stuff for us. Perhaps they can add shebang lines to=
 the top of every .pm and .pl file with a command-line switch indicating Pe=
rl 5. Perhaps they can add the &quot;use compat::perl5=E2=80=9D line (howev=
er it is spelled) at the top of each module/script. Perhaps all Perl 5 modu=
les are installed with the suffix .pm5, and Perl 7 is taught to look for th=
ose alongside .pm and .pmc. Perhaps all files with a .pl5 extension are par=
sed with Perl 5 compatibility, and the tooling automatically switches .pl t=
o .pl5. And finally, the tooling can be more conservative than the language=
 when it comes to defaults. No targeted Major version? Tooling can assume P=
erl 5 until 2040 for all I care.</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">In short, I don&#39;t believe that CPAN-compatibility needs to be=
 solved at the language level. Giving new users all the shiny bits out of t=
he box *for* *free* is really appealing to me. This is do important to me t=
hat I will step up and help with the tooling if that is the route that make=
s the most sense, and I bet I&#39;m not alone.</div><div dir=3D"auto"><br><=
/div><div dir=3D"auto">David</div></div><br><div class=3D"gmail_quote"><div=
 dir=3D"ltr" class=3D"gmail_attr">On Sun, Jun 28, 2020, 3:13 PM Eric Wong &=
lt;<a href=3D"mailto:p5p@yhbt.net">p5p@yhbt.net</a>&gt; wrote:<br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex">Todd Rinaldo &lt;<a href=3D"mailto:toddr@cpanel=
..net" target=3D"_blank" rel=3D"noreferrer">toddr@cpanel.net</a>&gt; wrote:<=
br>
&gt; &gt; On Jun 26, 2020, at 4:56 PM, Eric Wong &lt;<a href=3D"mailto:p5p@=
yhbt.net" target=3D"_blank" rel=3D"noreferrer">p5p@yhbt.net</a>&gt; wrote:<=
br>
&gt; &gt; <br>
&gt; &gt; Scripting languages like Perl, Python, Ruby, Tcl have<br>
&gt; &gt; significantly less room to evolve than compiled languages once<br=
>
&gt; &gt; they&#39;ve reached critical mass.<br>
&gt; &gt; <br>
&gt; &gt; JavaScript is an exception.=C2=A0 For most users it&#39;s shipped=
 with a<br>
&gt; &gt; complex browser which requires constant updates, anyways.=C2=A0 I=
<br>
&gt; &gt; can&#39;t say I know much about NodeJS, but I do hear about debac=
les<br>
&gt; &gt; (e.g. &quot;leftpad&quot;) and stay clear of it.<br>
&gt; <br>
&gt; You left out PHP which has added/removed stuff regularly as it<br>
&gt; has bumped versions. To my knowledge their user base has grown<br>
&gt; not shrunk as they made those changes. <br>
<br>
True, I don&#39;t know much about PHP, but my limited understanding<br>
is that it&#39;s far less used for tooling (build systems, packaging<br>
systems, CLI tools) than the others.=C2=A0 It&#39;s certainly not part of<b=
r>
default OS installs the way Perl and Python tend to be.<br>
<br>
Honestly, I think Perl could appeal to newbies (and maybe<br>
returning old schoolers) who&#39;ve been bitten by the Python 2/3<br>
mess.<br>
</blockquote></div>

--000000000000ca63cf05a92df8cb--
0
dcmertens
6/29/2020 12:15:45 AM
--0000000000002fcd7505a92e963d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, Jun 28, 2020 at 8:16 PM David Mertens <dcmertens.perl@gmail.com>
wrote:

> While it's fun to get into the weeds, I am convinced that any technical
> problem can be solved by the fine people on this list. I have faith in th=
e
> Perl community's creativity and resourcefulness. That means that the more
> important thing is to make the decision. Sawyer has done this, and has
> explained why he made those design choices in his talk.
>
> Now we have the fun of implementing a practical solution.
>
> Up to this point the discussion has focused on trying to solve technical
> issues at the language level. Must we? Can't we solve some of these with
> tooling?
>
> As an example, consider a distribution written targeting Perl5 (which is
> all of CPAN at the moment). When you try to install it under Perl7, EU::M=
M
> or M::B know that you are installing it under v7. With a little metadata
> (and sane defaults) these tools can be told the distribution targets Perl
> 5. In that case they can do all kinds of stuff for us. Perhaps they can a=
dd
> shebang lines to the top of every .pm and .pl file with a command-line
> switch indicating Perl 5. Perhaps they can add the "use compat::perl5=E2=
=80=9D line
> (however it is spelled) at the top of each module/script. Perhaps all Per=
l
> 5 modules are installed with the suffix .pm5, and Perl 7 is taught to loo=
k
> for those alongside .pm and .pmc. Perhaps all files with a .pl5 extension
> are parsed with Perl 5 compatibility, and the tooling automatically
> switches .pl to .pl5. And finally, the tooling can be more conservative
> than the language when it comes to defaults. No targeted Major version?
> Tooling can assume Perl 5 until 2040 for all I care.
>
> In short, I don't believe that CPAN-compatibility needs to be solved at
> the language level. Giving new users all the shiny bits out of the box
> *for* *free* is really appealing to me. This is do important to me that I
> will step up and help with the tooling if that is the route that makes th=
e
> most sense, and I bet I'm not alone.
>

I don't think it's accurate to categorize the concerns as "getting into the
weeds". This is a discussion on the fundamental design goal and how to best
achieve that. It is not a good idea to come up with designs and hope that
all practical concerns will just get sorted out as we go. Otherwise, one
could easily propose any number of fantastic designs for Perl that would,
sure, result in a better product, like changing how sigils work so they are
like in Raku. The practicalities of doing that in a language currently in
use must be weighed to determine the merit of that design goal.

You propose a number of options for working around the CPAN problem, which
is just one hurdle this proposal must overcome. I think each of them demand
a healthy discussion in how and whether it should be done. To start with,
having installers inject code into CPAN modules is both a licensing and
technical issue. The artistic license does not permit modifying the code
without changing the name. Injecting code changes line numbers from what
you find on CPAN. Can these be solved? Perhaps, but not without discussing
these things.

Which leads to my previous conclusion: we must weigh the effort of solving
all of these problems we are deciding to introduce, against the benefit of
turning on features by default instead of simply providing a useful "use
v7" pragma.

-Dan

--0000000000002fcd7505a92e963d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Sun, Jun 28, 2020 at 8:16 PM David Mer=
tens &lt;<a href=3D"mailto:dcmertens.perl@gmail.com">dcmertens.perl@gmail.c=
om</a>&gt; wrote:<br></div><div class=3D"gmail_quote"><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex"><div dir=3D"auto">While it&#39;s fun to get in=
to the weeds, I am convinced that any technical problem can be solved by th=
e fine people on this list. I have faith in the Perl community&#39;s creati=
vity and resourcefulness. That means that the more important thing is to ma=
ke the decision. Sawyer has done this, and has explained why he made those =
design choices in his talk.<div dir=3D"auto"><br></div><div dir=3D"auto">No=
w we have the fun of implementing a practical solution.</div><div dir=3D"au=
to"><br></div><div dir=3D"auto">Up to this point the discussion has focused=
 on trying to solve technical issues at the language level. Must we? Can&#3=
9;t we solve some of these with tooling?</div><div dir=3D"auto"><br></div><=
div dir=3D"auto">As an example, consider a distribution written targeting P=
erl5 (which is all of CPAN at the moment). When you try to install it under=
 Perl7, EU::MM or M::B know that you are installing it under v7. With a lit=
tle metadata (and sane defaults) these tools can be told the distribution t=
argets Perl 5. In that case they can do all kinds of stuff for us. Perhaps =
they can add shebang lines to the top of every .pm and .pl file with a comm=
and-line switch indicating Perl 5. Perhaps they can add the &quot;use compa=
t::perl5=E2=80=9D line (however it is spelled) at the top of each module/sc=
ript. Perhaps all Perl 5 modules are installed with the suffix .pm5, and Pe=
rl 7 is taught to look for those alongside .pm and .pmc. Perhaps all files =
with a .pl5 extension are parsed with Perl 5 compatibility, and the tooling=
 automatically switches .pl to .pl5. And finally, the tooling can be more c=
onservative than the language when it comes to defaults. No targeted Major =
version? Tooling can assume Perl 5 until 2040 for all I care.</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">In short, I don&#39;t believe that CP=
AN-compatibility needs to be solved at the language level. Giving new users=
 all the shiny bits out of the box *for* *free* is really appealing to me. =
This is do important to me that I will step up and help with the tooling if=
 that is the route that makes the most sense, and I bet I&#39;m not alone.<=
/div></div></blockquote><div><br></div><div>I don&#39;t think it&#39;s accu=
rate to categorize the concerns as &quot;getting into the weeds&quot;. This=
 is a discussion on the fundamental design goal and how to best achieve tha=
t. It is not a good idea to come up with designs and hope that all practica=
l concerns will just get sorted out as we go. Otherwise, one could easily p=
ropose any number of fantastic designs for Perl that would, sure, result in=
 a better product, like changing how sigils work so they are like in Raku. =
The practicalities of doing that in a language currently in use must be wei=
ghed to determine the merit of that design goal.</div><div><br></div><div>Y=
ou propose a number of options for working around the CPAN problem, which i=
s just one hurdle this proposal must overcome. I think each of them demand =
a healthy discussion in how and whether it should be done. To start with, h=
aving installers inject code into CPAN modules is both a licensing and tech=
nical issue. The artistic license does not permit modifying the code withou=
t changing the name. Injecting code changes line numbers from what you find=
 on CPAN. Can these be solved? Perhaps, but not without discussing these th=
ings.</div><div><br></div><div>Which leads to my previous conclusion: we mu=
st weigh the effort of solving all of these problems we are deciding to int=
roduce, against the benefit of turning on features by default instead of si=
mply providing a useful &quot;use v7&quot; pragma.</div><div><br></div><div=
>-Dan=C2=A0</div></div></div>

--0000000000002fcd7505a92e963d--
0
grinnz
6/29/2020 1:00:11 AM
I feel the best all-around solution here is for the Perl interpreter as of 
version 7.0.0 to make it mandatory to have the "use N;" (where N is a version 
number) tiny boilerplate at the top of each Perl file it runs.

This boilerplate has the same meaning it always had but it is now mandatory 
rather than optional.

This simple solution is a have our cake and eat it too thing.

By forcing a declaration, authors explicitly say what baseline behavior that 
they expect, and that can either be 5 or 7, but they say it explicitly.

Then the discussion is no longer the contentious what do you get when no version 
is specified, but rather what reasonable action does the Perl 7+ interpreter 
take when encountering a particular version declaration.  Most of the discussion 
here then is that the default behavior of Perl interpreter 7 is what happens 
when "use 7" is in a file.

Perl 5 code with appropriate "use 5" will continue to behave as it did before 
under a Perl 5 interpreter, and the Perl 7 interpreter will also permit it to 
run, and know what is expected.

The Perl 7+ interpreters can still remove older features so that certain Perl 5 
code will no longer run, but in that case they can separately give the error 
that eg 5.6 behavior is not supported, and the error can be customized based on 
the file's declared version that indicated what the author expected.

See https://www.nntp.perl.org/group/perl.perl5.porters/2020/06/msg257607.html 
where I previously talked about this at greater length.  I'm saying this again 
as I feel my prior message may not have been seen in the haystack or because I 
wasn't subscribed to the list then but now I am.

If we simply get away from the idea that Perl is best without any version 
declaration at all, the better off we'll be.

-- Darren Duncan
0
darren
6/29/2020 1:05:36 AM
On Mon, Jun 29, 2020 at 3:00 AM Dan Book <grinnz@gmail.com> wrote:
> This is a discussion on the fundamental design goal and how to best achie=
ve that. It is not a good idea to come up with designs and hope that all pr=
actical concerns will just get sorted out as we go. Otherwise, one could ea=
sily propose any number of fantastic designs for Perl that would, sure, res=
ult in a better product, like changing how sigils work so they are like in =
Raku. The practicalities of doing that in a language currently in use must =
be weighed to determine the merit of that design goal.

A lot of the discussion in this thread is about the design, when we
probably should be agreeing on the requirements (e.g. goals and
constraints) first. Everyone is talking past each other, because
everyone is judging the design by different requirements.

Leon
0
fawaka
6/29/2020 1:08:21 AM
On Sat, Jun 27, 2020 at 5:20 PM Sawyer X <xsawyerx@gmail.com> wrote:
> We (and this "we" includes you, Leon) know for a very long time now
> that p5p, the mailing list, is not a very practical place to discuss
> major changes. It is the primary reason we held summits in person -
> all of which you attended. We had discussed numerous topics and
> vocalized our agreement that it would have taken far longer (and
> possibly not had been resolved) if we had done it on the list, such as
> the decision of dates and versions for the elimination of all
> deprecated syntax. The last summit (near end of 2019) is when we first
> raised these ideas, by the way. Discussions of which you also attended
> in person.
>
> The list is a good place to bikeshed, get ideas, and suggest some
> topics, but it is rarely a practical arena to make large-scale
> decisions. I'm quite surprised that you expressed surprise at this
> since you attend the summits and know this for longer than I have.

I agree this list is not a practical list for a lot of purposes. I
completely understand developing a proposal off-list. But not
involving the list at all before publishing it to the outside world is
another extreme.

> This is incorrect, Leon. Everyone that was involved with this was in a
> shared file and viewable by everyone else. It was clear who was
> involved. We also had discussion threads that I initiated and tried to
> keep going. The "to" list was open, as you well know. Furthermore, we
> held multiple meetings in which we discussed it. It was not the cloak
> and dagger that you're describing here. I recall one meeting with you
> that took place until 2 or 3 am.

That was not my experience at all, and I'm not alone at that. That
document was locked up so tightly that I couldn't even print it or
copy from it, I definitely couldn't look up who was in it unless they
publicly commented on it. And that group email was rather an
incomplete list.

> This is also incorrect. We have been working on this for over half a
> year. We had numerous conversations on it with a staggering amount of
> stakeholders. The picture you paint is incorrect and in that regard,
> also unfair.

If those conversations are private they don't count as a community
consensus to me. I'd rather hear people speak for themselves.

> > Because right now it feels like we're strapped to a rocket with 10
> > seconds to lift-off, and I didn't sign up for that.
>
> Again, this is an incorrect representation, because we (including you
> and I) have been discussing it for a while now. Your participation in
> it was limited - by your own choice - and now you come back with "this
> is all so sudden to me." It isn't.

I may have known much more than most, but what I did not know is that
this would be communicated to the outside world as a done deal. The
Plan for Perl document certainly didn't say that.

Leon
0
fawaka
6/29/2020 2:08:06 AM
On Fri, Jun 26, 2020 at 10:42:30PM +0300, Sawyer X wrote:
> 2. "use v" turns on *everything* till this version.

"use v" turns on whatever we choose to turn on for that version, and
turns off all other features.  If we choose, use v7 can disable the
indirect "feature", or multidimensional if that's merged.

Tony
0
tony
6/29/2020 5:31:53 AM
On 2020-06-28 10:31 p.m., Tony Cook wrote:
> On Fri, Jun 26, 2020 at 10:42:30PM +0300, Sawyer X wrote:
>> 2. "use v" turns on *everything* till this version.
> 
> "use v" turns on whatever we choose to turn on for that version, and
> turns off all other features.  If we choose, use v7 can disable the
> indirect "feature", or multidimensional if that's merged.

That's right.  Saying "use v7" does not mean turning on all the features that 
exist, it only means turn on or off all the features we want on or off by 
default for Perl 7.  What it turns on is exactly the same set as is under 
discussion as the Perl 7 defaults. -- Darren Duncan
0
darren
6/29/2020 5:44:07 AM
--00000000000057205605a9338c85
Content-Type: text/plain; charset="UTF-8"

First let me state I do not oppose the whole effort.
I totally agree with Sawyer's effort evaluation as presented on CiC.
I disagree with the distribution of present and future costs of active
and new users (as I perceive it) .

* Predictability and continuity

Defining next release as an old release + some features by default can
become a great advantage of language, easy to advertise.

I'd go further with extending definition of feature live cycle,
- release X - feature enabled by default
- release X+1 - feature disable will be available but deprecated
- release X+2 - get rid of trash

This can add a great value in the predictability of language development.

This may slow down some improvements but I believe that focus on TCO is the
future of perl.

We should learn from known mistakes, failures, and good examples especially
in
this topic.

* "nobody knows individual features"

RFC idea: what about preparing eg [Anki][https://ankiweb.net] flashcard deck
with all capabilities, features and deprecations? With good design (based on
POD) it may be available for CPAN modules as well.

* Compile-time defaults

Difference between X and X+1 should may also suggest different compile time
default values. This process should be defined, with continuity in mind as
well.

* Language version specification

David Mitchell has a good point about "use v7".

Extending Philippe Bruhat's idea of mandatory version spec with behaviour:
- "no vX" will pass also on v(X+1) and v(X+2) and will disable all necessary
  features with respective deprecation notes
- "use vX" will pass also on v(X-1) and will allow all necessary features
- "use vX" should pass also in v(X-2), at least turning on deprecation and
  removal of known features (maybe via new pragma?)

Such an arrangement will allow users to use newer binary with predictable
behaviour. It will also allow simple grep based mechanisms to monitor
progress. Again, great value to propagate, stressing on language continuous
development and its predictability.

If will also allow to continue development in single code base (though I
agree
that current perl5 code base is not in optimal shape)

Ad Sawyer's note: "use statement needs to be added by someone"

Apart from the fact that this change can be done by script, this change is
one-time change. Assuming suggestions from this summary will be adapted this
change will decrease future maintenance.

Ad: "use v" turns on *everything* till this version

Unique time to change it is now. Eg "till this version in this major
version"

Ad: Vadim Konovalov's "Are there any modern languages that require some
version"

Every language requires some version, but for whole project via tooling
configuration. Ability to specify exact version in source code allows you to
adapt a new revision of language before you'll adapt the whole code base.

* "To release 5.32.0 as 7 would be a mistake for many reasons"

(citing Karen Etheridge)

Definining 7.0.0 as 5.32.0 is IMHO good idea but is a pattern that should
be strictly followed, so for example 5.33.1 should become 7.1.1.

Anyway, I will rather use "perl 7 base line is 5.32.0".

* CPAN support

CPAN should somehow support also unmaintained module versions, eg (release
date order):
- Foo::Bar v1.00 is v5
- Foo::Bar v2.00 is v7
- Foo::Bar v1.10 is v5
- Foo::Bar v2.50 is v8
- Foo::Bar v1.20 is v5

People using unmainted versions of perl should still have access to CPAN
modules suitable for their version of perl as well as module maintainters
should be able to support such versions.

* ad Paul "LeoNerd" Evans' tidy/critic and try

This is a greater problem than just try/catch. This problem will affect
every
custom keyword and operator. IMHO the ability to extend language with DSL
will be
crucial language feature in 5-or-so years.

Offtopic: IMHO try/catch should remain in the module, only the CATCH
feature should be
provided by the language.




On Wed, 24 Jun 2020 at 22:49, Sawyer X <xsawyerx@gmail.com> wrote:

> Hi everyone,
>
> 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.
> * Major versions will be used for two purposes: 1. Turn on features
> and pragmas by default, 2. Remove syntax from the language.
> * Features will be guarded within a major version (that is, one *must*
> enable new features in 7.x with "use feature") but will be turned on
> in the next major version.
> * Perl 7.0.0 will be the first release. It will effectively be 5.32.0
> with a small number of pragmas (at the very least, strict and
> warnings) and features. The goal is to make it as trivial as possible
> to upgrade from 5.32.0 to 7.0.0.
> * Perl 5 will enter a long-term support window - 5+ years. Exact
> number not determined yet.
> * We intend to release 7.0.0 within a year. However, I am setting the
> goal of releasing it before the end of this year. I want to pave the
> way for 7.1.0, which will have the stable release of 7.2.0.
> * We will introduce utilities to help upgrade code to Perl 7. For
> example, if we were to add signatures by default in 7.0.0 (only *for
> example*), we will need code that helps users rewrite "sub foo ($)" as
> "sub foo :prototype($)".
> * We will also introduce a "compat::perl5" module, which will turn
> back the defaults of pragmas and features on 5.32.0. With this change,
> one could upgrade to Perl 7 binary immediately without changing the
> code. It allows a longer upgrade path.
> * We will also introduce a module to help fix up other modules. Such a
> module will especially help toolchain and infrastructure for CPAN
> manage the automatic upgrade or downgrade of modules without the user
> having to fix the code they are installing if it's incompatible.
>
> It would be hard to repeat everything in the talk, so I recommend
> watching the talk. The short and sweet is: We need to prioritize users
> who *write* Perl versus users who explicitly refuse or cannot update
> their code. In our current prioritization, we force all existing users
> and new users to manage the technical debt of previous generations.
>
> There is *a lot* to figure out at this point. We need to:
> * Update the internal code to support "use strict" and "use warnings".
> * Bump to 7.0.0.
> * Determine which pragmas and features will be enabled and turned on.
> * Determine how long we will support Perl version 5.
> * Determine the criteria for bumping major versions. Time might not be
> the best metric.
> * Create tickets for issues to be done so that the community could
> help. (People have already reached out, wanting to support this
> effort.)
> * Make sure we clarify what gets backported to Perl 5.32.x. Right now,
> it's the same criteria as every other maint release, except for a much
> longer time-frame.
> * Work on moving to 7.0.0 is already underway on the p7 branch here:
> https://github.com/atoomic/perl
>
> Additional comments:
> * Yearly releases for minor versions will continue as planned.
> * Monthly releases for dev versions will continue as planned.
> * See Perl 7.0.0 as 5.32.0 (+ some new defaults), 7.1.0 as 5.33.1.
> 7.2.0 will be akin to 5.34.0.
> * As exciting as 7.0.0 will be, it will mostly be there just to put us
> on our path. 8.0.0 will likely be much exciting.
> * There are notable stakeholders to the language which will be working
> with us to update their code to 7.0.0 defaults, to help understand the
> possible consequences.
> * We will need to rename the GitHub repo. That's okay because GitHub
> creates an automatic redirect for the URLs, including the GitHub clone
> paths.
> * /usr/bin/perl is owned by distributions. We are not in charge of it.
> We will be providing support to vendors and distributions and help
> them reach good decisions and move forward in the manner they choose.
>
> I apologize for not sharing this news earlier. We have been working on
> this plan for a very long time. p5p is a public mailing list, and we
> needed to manage the communication around this. Despite not being
> public, many people worked on it. Vital core developers, numerous core
> contributors, several significant stakeholders, vendors/distributions,
> and people with an in-depth history in Perl and the core code - were
> all involved. We have done a *lot* of work to get to where we are.
> While it's not a fully detailed change proposal, we have gone through
> quite a lot and tried to be very thorough while leaving room for
> things to now be openly discussed.
>
> Several threads will likely begin on the list to address specific
> issues listed above. I imagine this thread will itself receive a lot
> of responses and soon become sprawling. To manage this, I will open
> several threads, over several weeks, so we could have "waves" of
> discussions, instead of one monster thread in which we might quickly
> lose both our place and our focus. When discussing these topics, I
> request people to communicate mindfully and constructively.
>
> I want to thank everyone who helped work on this plan and shape it
> into what it is today. These are too many people to mention, but I
> want you to know I appreciate the effort, the time, the thorough
> reviews, the feedback, the ideas, and the solutions.
>
> Sawyer.
>
> [1] https://www.youtube.com/watch?v=6wPMh-3qYJM
>

--00000000000057205605a9338c85
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>First let me state I do not oppose the whole effort. <=
br>I totally agree with Sawyer&#39;s effort evaluation as presented on CiC.=
<br><div>I disagree with the distribution of present and future costs of ac=
tive</div><div> and new users  (as I perceive it) .</div><br>* Predictabili=
ty and continuity<br><br>Defining next release as an old release + some fea=
tures by default can<br>become a great advantage of language, easy to adver=
tise.<br><br>I&#39;d go further with extending definition of feature live c=
ycle,<br>- release X - feature enabled by default<br>- release X+1 - featur=
e disable will be available but deprecated<br>- release X+2 - get rid of tr=
ash<br><br>This can add a great value in the predictability of language dev=
elopment.<br><br>This may slow down some improvements but I believe that fo=
cus on TCO is the<br>future of perl.<br><br>We should learn from known mist=
akes, failures, and good examples especially in<br>this topic.<br><br>* &qu=
ot;nobody knows individual features&quot;<br><br>RFC idea: what about prepa=
ring eg [Anki][<a href=3D"https://ankiweb.net">https://ankiweb.net</a>] fla=
shcard deck<br>with all capabilities, features and deprecations? With good =
design (based on<br>POD) it may be available for CPAN modules as well.<br><=
br>* Compile-time defaults<br><br>Difference between X and X+1 should may a=
lso suggest different compile time<br>default values. This process should b=
e defined, with continuity in mind as<br>well.<br><br>* Language version sp=
ecification<br><br>David Mitchell has a good point about &quot;use v7&quot;=
..<br><br>Extending Philippe Bruhat&#39;s idea of mandatory version spec wit=
h behaviour:<br>- &quot;no vX&quot; will pass also on v(X+1) and v(X+2) and=
 will disable all necessary<br>=C2=A0 features with respective deprecation =
notes<br>- &quot;use vX&quot; will pass also on v(X-1) and will allow all n=
ecessary features<br>- &quot;use vX&quot; should pass also in v(X-2), at le=
ast turning on deprecation and<br>=C2=A0 removal of known features (maybe v=
ia new pragma?)<br><br>Such an arrangement will allow users to use newer bi=
nary with predictable<br>behaviour. It will also allow simple grep based me=
chanisms to monitor<br>progress. Again, great value to propagate, stressing=
 on language continuous<br>development and its predictability.<br><br>If wi=
ll also allow to continue development in single code base (though I agree<b=
r>that current perl5 code base is not in optimal shape)<br><br>Ad Sawyer&#3=
9;s note: &quot;use statement needs to be added by someone&quot;<br><br>Apa=
rt from the fact that this change can be done by script, this change is<br>=
one-time change. Assuming suggestions from this summary will be adapted thi=
s<br>change will decrease future maintenance.<br><br>Ad: &quot;use v&quot; =
turns on *everything* till this version<br><br>Unique time to change it is =
now. Eg &quot;till this version in this major version&quot;<br><br>Ad: Vadi=
m Konovalov&#39;s &quot;Are there any modern languages that require some<br=
>version&quot;<br><br>Every language requires some version, but for whole p=
roject via tooling<br>configuration. Ability to specify exact version in so=
urce code allows you to<br>adapt a new revision of language before you&#39;=
ll adapt the whole code base.<br><br>* &quot;To release 5.32.0 as 7 would b=
e a mistake for many reasons&quot;<br><br>(citing Karen Etheridge)<br><br>D=
efinining 7.0.0 as 5.32.0 is IMHO good idea but is a pattern that should<br=
>be strictly followed, so for example 5.33.1 should become 7.1.1.<br><br>An=
yway, I will rather use &quot;perl 7 base line is 5.32.0&quot;.<br><br>* CP=
AN support<br><br>CPAN should somehow support also unmaintained module vers=
ions, eg (release<br>date order):<br>- Foo::Bar v1.00 is v5<br>- Foo::Bar v=
2.00 is v7<br>- Foo::Bar v1.10 is v5<br>- Foo::Bar v2.50 is v8<br>- Foo::Ba=
r v1.20 is v5<br><br>People using unmainted versions of perl should still h=
ave access to CPAN<br>modules suitable for their version of perl as well as=
 module maintainters<br>should be able to support such versions.<br><br>* a=
d Paul &quot;LeoNerd&quot; Evans&#39; tidy/critic and try<br><br>This is a =
greater problem than just try/catch. This problem will affect every<br>cust=
om keyword and operator. IMHO the ability to extend language with DSL will =
be<br>crucial language feature in 5-or-so years.<br><br>Offtopic: IMHO try/=
catch should remain in the module, only the CATCH feature should be<br>prov=
ided by the language.<br><br><br><br></div><br><div class=3D"gmail_quote"><=
div dir=3D"ltr" class=3D"gmail_attr">On Wed, 24 Jun 2020 at 22:49, Sawyer X=
 &lt;<a href=3D"mailto:xsawyerx@gmail.com">xsawyerx@gmail.com</a>&gt; wrote=
:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi everyone,<b=
r>
<br>
A little while ago, I gave a talk[1] at The Perl Conference in the<br>
Cloud where I covered the Plan for Perl that includes the following<br>
significant changes:<br>
<br>
* We will begin using major versions again, starting with version 7.<br>
* Major versions will be used for two purposes: 1. Turn on features<br>
and pragmas by default, 2. Remove syntax from the language.<br>
* Features will be guarded within a major version (that is, one *must*<br>
enable new features in 7.x with &quot;use feature&quot;) but will be turned=
 on<br>
in the next major version.<br>
* Perl 7.0.0 will be the first release. It will effectively be 5.32.0<br>
with a small number of pragmas (at the very least, strict and<br>
warnings) and features. The goal is to make it as trivial as possible<br>
to upgrade from 5.32.0 to 7.0.0.<br>
* Perl 5 will enter a long-term support window - 5+ years. Exact<br>
number not determined yet.<br>
* We intend to release 7.0.0 within a year. However, I am setting the<br>
goal of releasing it before the end of this year. I want to pave the<br>
way for 7.1.0, which will have the stable release of 7.2.0.<br>
* We will introduce utilities to help upgrade code to Perl 7. For<br>
example, if we were to add signatures by default in 7.0.0 (only *for<br>
example*), we will need code that helps users rewrite &quot;sub foo ($)&quo=
t; as<br>
&quot;sub foo :prototype($)&quot;.<br>
* We will also introduce a &quot;compat::perl5&quot; module, which will tur=
n<br>
back the defaults of pragmas and features on 5.32.0. With this change,<br>
one could upgrade to Perl 7 binary immediately without changing the<br>
code. It allows a longer upgrade path.<br>
* We will also introduce a module to help fix up other modules. Such a<br>
module will especially help toolchain and infrastructure for CPAN<br>
manage the automatic upgrade or downgrade of modules without the user<br>
having to fix the code they are installing if it&#39;s incompatible.<br>
<br>
It would be hard to repeat everything in the talk, so I recommend<br>
watching the talk. The short and sweet is: We need to prioritize users<br>
who *write* Perl versus users who explicitly refuse or cannot update<br>
their code. In our current prioritization, we force all existing users<br>
and new users to manage the technical debt of previous generations.<br>
<br>
There is *a lot* to figure out at this point. We need to:<br>
* Update the internal code to support &quot;use strict&quot; and &quot;use =
warnings&quot;.<br>
* Bump to 7.0.0.<br>
* Determine which pragmas and features will be enabled and turned on.<br>
* Determine how long we will support Perl version 5.<br>
* Determine the criteria for bumping major versions. Time might not be<br>
the best metric.<br>
* Create tickets for issues to be done so that the community could<br>
help. (People have already reached out, wanting to support this<br>
effort.)<br>
* Make sure we clarify what gets backported to Perl 5.32.x. Right now,<br>
it&#39;s the same criteria as every other maint release, except for a much<=
br>
longer time-frame.<br>
* Work on moving to 7.0.0 is already underway on the p7 branch here:<br>
<a href=3D"https://github.com/atoomic/perl" rel=3D"noreferrer" target=3D"_b=
lank">https://github.com/atoomic/perl</a><br>
<br>
Additional comments:<br>
* Yearly releases for minor versions will continue as planned.<br>
* Monthly releases for dev versions will continue as planned.<br>
* See Perl 7.0.0 as 5.32.0 (+ some new defaults), 7.1.0 as 5.33.1.<br>
7.2.0 will be akin to 5.34.0.<br>
* As exciting as 7.0.0 will be, it will mostly be there just to put us<br>
on our path. 8.0.0 will likely be much exciting.<br>
* There are notable stakeholders to the language which will be working<br>
with us to update their code to 7.0.0 defaults, to help understand the<br>
possible consequences.<br>
* We will need to rename the GitHub repo. That&#39;s okay because GitHub<br=
>
creates an automatic redirect for the URLs, including the GitHub clone<br>
paths.<br>
* /usr/bin/perl is owned by distributions. We are not in charge of it.<br>
We will be providing support to vendors and distributions and help<br>
them reach good decisions and move forward in the manner they choose.<br>
<br>
I apologize for not sharing this news earlier. We have been working on<br>
this plan for a very long time. p5p is a public mailing list, and we<br>
needed to manage the communication around this. Despite not being<br>
public, many people worked on it. Vital core developers, numerous core<br>
contributors, several significant stakeholders, vendors/distributions,<br>
and people with an in-depth history in Perl and the core code - were<br>
all involved. We have done a *lot* of work to get to where we are.<br>
While it&#39;s not a fully detailed change proposal, we have gone through<b=
r>
quite a lot and tried to be very thorough while leaving room for<br>
things to now be openly discussed.<br>
<br>
Several threads will likely begin on the list to address specific<br>
issues listed above. I imagine this thread will itself receive a lot<br>
of responses and soon become sprawling. To manage this, I will open<br>
several threads, over several weeks, so we could have &quot;waves&quot; of<=
br>
discussions, instead of one monster thread in which we might quickly<br>
lose both our place and our focus. When discussing these topics, I<br>
request people to communicate mindfully and constructively.<br>
<br>
I want to thank everyone who helped work on this plan and shape it<br>
into what it is today. These are too many people to mention, but I<br>
want you to know I appreciate the effort, the time, the thorough<br>
reviews, the feedback, the ideas, and the solutions.<br>
<br>
Sawyer.<br>
<br>
[1] <a href=3D"https://www.youtube.com/watch?v=3D6wPMh-3qYJM" rel=3D"norefe=
rrer" target=3D"_blank">https://www.youtube.com/watch?v=3D6wPMh-3qYJM</a><b=
r>
</blockquote></div>

--00000000000057205605a9338c85--
0
happy
6/29/2020 6:55:34 AM
On Sun, 28 Jun 2020 03:39:52 -0500
Todd Rinaldo <toddr@cpanel.net> wrote:

> Easily. They check $].

Todd, please explain how github's syntax highlighter checks the value
of $] when highlighting a .pm file.

Or for that matter even metacpan.org. How will our own infrastructure
know what version of perl syntax rules to be using when highlighting
our own code?

-- 
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk      |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/
0
leonerd
6/29/2020 8:56:10 AM
On Mon, 29 Jun 2020 09:56:10 +0100
"Paul \"LeoNerd\" Evans" <leonerd@leonerd.org.uk> wrote:

> On Sun, 28 Jun 2020 03:39:52 -0500
> Todd Rinaldo <toddr@cpanel.net> wrote:
> 
> > Easily. They check $].  
> 
> Todd, please explain how github's syntax highlighter checks the value
> of $] when highlighting a .pm file.
> 
> Or for that matter even metacpan.org. How will our own infrastructure
> know what version of perl syntax rules to be using when highlighting
> our own code?

Also for that matter; how will perlcritic/perltidy know?

I surely hope we are not going to end up with source-code tooling that
presumes that the version of Perl *running* the tooling must equal the
version of Perl that source code targets. I would hate to have to run
all of my tooling under perl5 just because I am working on a .pm file
that needs to be dual-life and target perl5 as well as perl7.

-- 
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk      |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/
0
leonerd
6/29/2020 9:04:59 AM
On Mon, 29 Jun 2020 11:04:59 +0200, Paul "LeoNerd" Evans <leonerd@leonerd.org.uk> wrote:

> On Mon, 29 Jun 2020 09:56:10 +0100
> "Paul \"LeoNerd\" Evans" <leonerd@leonerd.org.uk> wrote:
>
>> On Sun, 28 Jun 2020 03:39:52 -0500
>> Todd Rinaldo <toddr@cpanel.net> wrote:
>>
>> > Easily. They check $].
>>
>> Todd, please explain how github's syntax highlighter checks the value
>> of $] when highlighting a .pm file.
>>
>> Or for that matter even metacpan.org. How will our own infrastructure
>> know what version of perl syntax rules to be using when highlighting
>> our own code?
>
> Also for that matter; how will perlcritic/perltidy know?
>
> I surely hope we are not going to end up with source-code tooling that
> presumes that the version of Perl *running* the tooling must equal the
> version of Perl that source code targets. I would hate to have to run
> all of my tooling under perl5 just because I am working on a .pm file
> that needs to be dual-life and target perl5 as well as perl7.

https://www.nntp.perl.org/group/perl.perl5.porters/2020/06/msg257645.html

https://www.nntp.perl.org/group/perl.perl5.porters/2020/06/msg257646.html

At this point in time i see absolutely no reason, excuse or possibility to have PPI parse unversioned/unmarked code as anything but Perl 5, unless a user specifically indicates this desire.

Heck, maybe that's the compromise we end up with: Perl executable runs unversioned code as v7, but all documentation tells you to use v7; in case you ever want it to interface with toolchain.

-- 
With regards,
Christian Walde
0
walde
6/29/2020 6:53:12 PM
--00000000000010f2e505a93e6a31
Content-Type: text/plain; charset="UTF-8"

Dan made some important points that I wanted to respond to.

On Sun, Jun 28, 2020 at 9:00 PM Dan Book <grinnz@gmail.com> wrote:

> On Sun, Jun 28, 2020 at 8:16 PM David Mertens <dcmertens.perl@gmail.com>
> wrote:
>
>> While it's fun to get into the weeds, I am convinced that any technical
>> problem can be solved by the fine people on this list. I have faith in the
>> Perl community's creativity and resourcefulness. That means that the more
>> important thing is to make the decision. Sawyer has done this, and has
>> explained why he made those design choices in his talk.
>>
>> ... consider a distribution written targeting Perl5 (which is all of CPAN
>> at the moment). When you try to install it under Perl7, EU::MM or M::B know
>> that you are installing it under v7. With a little metadata (and sane
>> defaults) these tools can be told the distribution targets Perl 5. In that
>> case ... [p]erhaps all Perl 5 modules are installed with the suffix .pm5,
>> and Perl 7 is taught to look for those alongside .pm and .pmc. Perhaps all
>> files with a .pl5 extension are parsed with Perl 5 compatibility, and the
>> tooling automatically switches .pl to .pl5.
>>
>
> I don't think it's accurate to categorize the concerns as "getting into
> the weeds". This is a discussion on the fundamental design goal and how to
> best achieve that. It is not a good idea to come up with designs and hope
> that all practical concerns will just get sorted out as we go. Otherwise,
> one could easily propose any number of fantastic designs for Perl that
> would, sure, result in a better product, like changing how sigils work so
> they are like in Raku. The practicalities of doing that in a language
> currently in use must be weighed to determine the merit of that design goal.
>

I'll agree with you that having a clear picture of the thorny issues is
important. I just worry that parts of this discussion have gotten carried
away, focusing too much energy on finding problems rather than discussing
various solutions.


> You propose a number of options for working around the CPAN problem, which
> is just one hurdle this proposal must overcome.
>

I would wager it is the hardest hurdle to overcome. In my eyes, once we
overcome CPAN compatibility, every other problem falls somewhere between
"solved" and "trivial." I would really appreciate a sober outline of
problems that are *not* solved by fixing the CPAN tooling. Sure, you could
tell me that some company's internal code might have their own installation
systems. Fine. They can either update their installation software to
emulate what the new tooling does or they can simply not upgrade Perl. I
would bet that most shops actually use Perl's tooling, in which case they
can just upgrade their Perl version and re-install.


> I think each of them demand a healthy discussion in how and whether it
> should be done. To start with, having installers inject code into CPAN
> modules is both a licensing and technical issue. The artistic license does
> not permit modifying the code without changing the name.
>

I'm confused here. I thought the installers already modify the #! line of
scripts in the bin/ folder? Doesn't that violate the licensing? Also,
doesn't the file extension idea I suggested skirt licensing entirely?


> Injecting code changes line numbers from what you find on CPAN.
>

With a properly orchestrated #line comment, this can be fixed for any and
all line reporting by the Perl executable. Are you worried about somebody
looking at an installed module's source and comparing it to what they see
online? I think that a two-line difference is acceptable to get Perl5
compatibility, don't you? I surely wouldn't call this a non-starter.


> Can these be solved? Perhaps, but not without discussing these things.
>

Yes, they can be solved.


> Which leads to my previous conclusion: we must weigh the effort of solving
> all of these problems we are deciding to introduce, against the benefit of
> turning on features by default instead of simply providing a useful "use
> v7" pragma.
>

Yep. This comes down to the key question: who are we optimizing for?

Sawyer wants to optimize for the brand new user. On the face of it that
breaks CPAN compatibility. So everybody is trying to figure out how to
maintain CPAN compatibility. Your point is that different solutions will
take different amounts of effort, and we shouldn't sign ourselves up for
too much effort if we can avoid it. This was the folly of Perl6, so your
point is well taken.

I think tooling changes provide a relatively low cost way of getting what
Sawyer has proposed. It even gives us a longer window in which to really
deprecate Perl5 code on CPAN. (At some point, the tooling can decide to
stop defaulting to Perl5 if no major version is specified for a module.)
That means we can release a shiny, new, strict Perl 7 by Christmas (or
whenever), get all of CPAN, and deprecate Perl 5 as slowly as we want.

David

-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan

--00000000000010f2e505a93e6a31
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Dan made some important points that I wanted to respo=
nd to.<br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gm=
ail_attr">On Sun, Jun 28, 2020 at 9:00 PM Dan Book &lt;<a href=3D"mailto:gr=
innz@gmail.com">grinnz@gmail.com</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr">On Sun, =
Jun 28, 2020 at 8:16 PM David Mertens &lt;<a href=3D"mailto:dcmertens.perl@=
gmail.com" target=3D"_blank">dcmertens.perl@gmail.com</a>&gt; wrote:<br></d=
iv><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:=
1ex"><div dir=3D"auto">While it&#39;s fun to get into the weeds, I am convi=
nced that any technical problem can be solved by the fine people on this li=
st. I have faith in the Perl community&#39;s creativity and resourcefulness=
.. That means that the more important thing is to make the decision. Sawyer =
has done this, and has explained why he made those design choices in his ta=
lk.<div dir=3D"auto"><br></div>... consider a distribution written targetin=
g Perl5 (which is all of CPAN at the moment). When you try to install it un=
der Perl7, EU::MM or M::B know that you are installing it under v7. With a =
little metadata (and sane defaults) these tools can be told the distributio=
n targets Perl 5. In that case ... [p]erhaps all Perl 5 modules are install=
ed with the suffix .pm5, and Perl 7 is taught to look for those alongside .=
pm and .pmc. Perhaps all files with a .pl5 extension are parsed with Perl 5=
 compatibility, and the tooling automatically switches .pl to .pl5. <br></d=
iv></blockquote><div><br></div><div>I don&#39;t think it&#39;s accurate to =
categorize the concerns as &quot;getting into the weeds&quot;. This is a di=
scussion on the fundamental design goal and how to best achieve that. It is=
 not a good idea to come up with designs and hope that all practical concer=
ns will just get sorted out as we go. Otherwise, one could easily propose a=
ny number of fantastic designs for Perl that would, sure, result in a bette=
r product, like changing how sigils work so they are like in Raku. The prac=
ticalities of doing that in a language currently in use must be weighed to =
determine the merit of that design goal.</div></div></div></blockquote><div=
><br></div><div>I&#39;ll agree with you that having a clear picture of the =
thorny issues is important. I just worry that parts of this discussion have=
 gotten carried away, focusing too much energy on finding problems rather t=
han discussing various solutions.<br></div><div>=C2=A0</div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quo=
te"><div></div><div>You propose a number of options for working around the =
CPAN problem, which is just one hurdle this proposal must overcome.</div></=
div></div></blockquote><div><br></div><div>I would wager it is the hardest =
hurdle to overcome. In my eyes, once we overcome CPAN compatibility, every =
other problem falls somewhere between &quot;solved&quot; and &quot;trivial.=
&quot; I would really appreciate a sober outline of problems that are *not*=
 solved by fixing the CPAN tooling. Sure, you could tell me that some compa=
ny&#39;s internal code might have their own installation systems. Fine. The=
y can either update their installation software to emulate what the new too=
ling does or they can simply not upgrade Perl. I would bet that most shops =
actually use Perl&#39;s tooling, in which case they can just upgrade their =
Perl version and re-install.<br></div><div>=C2=A0</div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><=
div>I think each of them demand a healthy discussion in how and whether it =
should be done. To start with, having installers inject code into CPAN modu=
les is both a licensing and technical issue. The artistic license does not =
permit modifying the code without changing the name. </div></div></div></bl=
ockquote><div><br></div><div>I&#39;m confused here. I thought the installer=
s already modify the #! line of scripts in the bin/ folder? Doesn&#39;t tha=
t violate the licensing? Also, doesn&#39;t the file extension idea I sugges=
ted skirt licensing entirely?<br></div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote=
"><div>Injecting code changes line numbers from what you find on CPAN.</div=
></div></div></blockquote><div><br></div><div>With a properly orchestrated =
#line comment, this can be fixed for any and all line reporting by the Perl=
 executable. Are you worried about somebody looking at an installed module&=
#39;s source and comparing it to what they see online? I think that a two-l=
ine difference is acceptable to get Perl5 compatibility, don&#39;t you? I s=
urely wouldn&#39;t call this a non-starter.<br></div><div>=C2=A0</div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D=
"gmail_quote"><div>Can these be solved? Perhaps, but not without discussing=
 these things.</div></div></div></blockquote><div><br></div><div>Yes, they =
can be solved.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div></div><div=
>Which leads to my previous conclusion: we must weigh the effort of solving=
 all of these problems we are deciding to introduce, against the benefit of=
 turning on features by default instead of simply providing a useful &quot;=
use v7&quot; pragma.</div></div></div>
</blockquote></div><div><br></div><div>Yep. This comes down to the key ques=
tion: who are we optimizing for?</div><div><br></div><div>Sawyer wants to o=
ptimize for the brand new user. On the face of it that breaks CPAN compatib=
ility. So everybody is trying to figure out how to maintain CPAN compatibil=
ity. Your point is that different solutions will take different amounts of =
effort, and we shouldn&#39;t sign ourselves up for too much effort if we ca=
n avoid it. This was the folly of Perl6, so your point is well taken.</div>=
<div><br></div><div>I think tooling changes provide a relatively low cost w=
ay of getting what Sawyer has proposed. It even gives us a longer window in=
 which to really deprecate Perl5 code on CPAN. (At some point, the tooling =
can decide to stop defaulting to Perl5 if no major version is specified for=
 a module.) That means we can release a shiny, new, strict Perl 7 by Christ=
mas (or whenever), get all of CPAN, and deprecate Perl 5 as slowly as we wa=
nt.</div><div><br></div><div>David<br></div><br>-- <br><div dir=3D"ltr" cla=
ss=3D"gmail_signature">=C2=A0&quot;Debugging is twice as hard as writing th=
e code in the first place.<br>
 =C2=A0 Therefore, if you write the code as cleverly as possible, you are,<=
br>
 =C2=A0 by definition, not smart enough to debug it.&quot; -- Brian Kernigh=
an<br></div></div>

--00000000000010f2e505a93e6a31--
0
dcmertens
6/29/2020 7:53:24 PM
--000000000000d6d28705a93e7e5d
Content-Type: text/plain; charset="UTF-8"

On Mon, Jun 29, 2020 at 5:05 AM Paul "LeoNerd" Evans <leonerd@leonerd.org.uk>
wrote:

> On Mon, 29 Jun 2020 09:56:10 +0100
> "Paul \"LeoNerd\" Evans" <leonerd@leonerd.org.uk> wrote:
>
> > Todd, please explain how github's syntax highlighter checks the value
> > of $] when highlighting a .pm file.
> >
> > Or for that matter even metacpan.org. How will our own infrastructure
> > know what version of perl syntax rules to be using when highlighting
> > our own code?
>

Metacpan, at the very least, could check the distribution's metadata for
the major version(s) of Perl on which the code will install.


> Also for that matter; how will perlcritic/perltidy know?
>

If we require a back-compat module, then it's trivial. If we use file
extensions, it's also trivial.


> I surely hope we are not going to end up with source-code tooling that
> presumes that the version of Perl *running* the tooling must equal the
> version of Perl that source code targets. I would hate to have to run
> all of my tooling under perl5 just because I am working on a .pm file
> that needs to be dual-life and target perl5 as well as perl7.
>

What's wrong with that assumption? Also, I'm not sure exactly what tooling
you're talking about, but surely perlcritic and perltidy could be given
command-line switches to use the "other" version of Perl, right?

I strongly suspect that the vast majority of Perl code will run fine under
Perl 5 and 7. Subroutine signatures appear to be an interesting corner
case, but I don't see why that needs to hold up the parade here.

David

-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan

--000000000000d6d28705a93e7e5d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail=
_attr">On Mon, Jun 29, 2020 at 5:05 AM Paul &quot;LeoNerd&quot; Evans &lt;<=
a href=3D"mailto:leonerd@leonerd.org.uk">leonerd@leonerd.org.uk</a>&gt; wro=
te:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, 29 J=
un 2020 09:56:10 +0100<br>
&quot;Paul \&quot;LeoNerd\&quot; Evans&quot; &lt;<a href=3D"mailto:leonerd@=
leonerd.org.uk" target=3D"_blank">leonerd@leonerd.org.uk</a>&gt; wrote:<br>
<br>&gt; Todd, please explain how github&#39;s syntax highlighter checks th=
e value<br>
&gt; of $] when highlighting a .pm file.<br>
&gt; <br>
&gt; Or for that matter even <a href=3D"http://metacpan.org" rel=3D"norefer=
rer" target=3D"_blank">metacpan.org</a>. How will our own infrastructure<br=
>
&gt; know what version of perl syntax rules to be using when highlighting<b=
r>
&gt; our own code?<br></blockquote><div><br></div><div>Metacpan, at the ver=
y least, could check the distribution&#39;s metadata for the major version(=
s) of Perl on which the code will install.<br></div><div>=C2=A0</div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex">

Also for that matter; how will perlcritic/perltidy know?<br></blockquote><d=
iv><br></div><div>If we require a back-compat module, then it&#39;s trivial=
.. If we use file extensions, it&#39;s also trivial.<br></div><div>=C2=A0</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex">

I surely hope we are not going to end up with source-code tooling that<br>
presumes that the version of Perl *running* the tooling must equal the<br>
version of Perl that source code targets. I would hate to have to run<br>
all of my tooling under perl5 just because I am working on a .pm file<br>
that needs to be dual-life and target perl5 as well as perl7.<br></blockquo=
te><div><br></div><div>What&#39;s wrong with that assumption? Also, I&#39;m=
 not sure exactly what tooling you&#39;re talking about, but surely perlcri=
tic and perltidy could be given command-line switches to use the &quot;othe=
r&quot; version of Perl, right?<br></div><div><br></div><div>I strongly sus=
pect that the vast majority of Perl code will run fine under Perl 5 and 7. =
Subroutine signatures appear to be an interesting corner case, but I don&#3=
9;t see why that needs to hold up the parade here.</div><div><br></div><div=
>David<br></div><br></div>-- <br><div dir=3D"ltr" class=3D"gmail_signature"=
>=C2=A0&quot;Debugging is twice as hard as writing the code in the first pl=
ace.<br>
 =C2=A0 Therefore, if you write the code as cleverly as possible, you are,<=
br>
 =C2=A0 by definition, not smart enough to debug it.&quot; -- Brian Kernigh=
an<br></div></div>

--000000000000d6d28705a93e7e5d--
0
dcmertens
6/29/2020 7:59:13 PM
--000000000000d6234d05a93e90e3
Content-Type: text/plain; charset="UTF-8"

On Mon, Jun 29, 2020 at 12:59 PM David Mertens <dcmertens.perl@gmail.com>
wrote:

> I strongly suspect that the vast majority of Perl code will run fine under
> Perl 5 and 7. Subroutine signatures appear to be an interesting corner
> case, but I don't see why that needs to hold up the parade here.
>

That's the thing -- we just don't know yet. Until we try out at least one
(but preferably more than one) way forward and smoke a good chunk of cpan
against it, we're just guessing.

--000000000000d6234d05a93e90e3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon=
t-size:small"><br></div></div><div class=3D"gmail_quote"><div dir=3D"ltr" c=
lass=3D"gmail_attr">On Mon, Jun 29, 2020 at 12:59 PM David Mertens &lt;<a h=
ref=3D"mailto:dcmertens.perl@gmail.com">dcmertens.perl@gmail.com</a>&gt; wr=
ote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D=
"ltr"><div class=3D"gmail_quote">I strongly suspect that the vast majority =
of Perl code will run fine under Perl 5 and 7. Subroutine signatures appear=
 to be an interesting corner case, but I don&#39;t see why that needs to ho=
ld up the parade here.</div></div></blockquote><div><br></div><div style=3D=
"font-size:small" class=3D"gmail_default">That&#39;s the thing -- we just d=
on&#39;t know yet. Until we try out at least one (but preferably more than =
one) way forward and smoke a good chunk of cpan against it, we&#39;re just =
guessing.</div><div style=3D"font-size:small" class=3D"gmail_default"><br><=
/div></div></div>

--000000000000d6234d05a93e90e3--
0
perl
6/29/2020 8:04:10 PM
--=-7909yW7+UX5+hQaVXMcz
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: quoted-printable

On Sun, 2020-06-28 at 19:23 +0200, Christian Walde wrote:
> On Fri, 26 Jun 2020 20:57:39 +0200, John Lightsey <john@nixnuts.net> wrot=
e:
>=20
> > I'd love to see Perl 8 fix [...] Windows support.
>=20
> 2 things here:
>=20
> 1. Please don't phrase it in a way that implies Perl doesn't support wind=
ows. I've been developing Perl on windows for over a decade and it works.
>=20
> 2. Out of curiosity, what specific points do you care about here?
>=20

I was thinking specifically about the problems with subprocess creation
since I spent time looking at them recently:

https://github.com/Perl/perl5/issues/14434

My understanding is that the fork() implementation in Perl also tends to
cause confusion compared to the way Python or Ruby handle fork() calls
on Windows.

I apologize if my remarks implied Perl doesn't work on Windows. My
intent was to argue that it could be better.

--=-7909yW7+UX5+hQaVXMcz
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEGNgF+IF46Km9DAl95E+AFtNjD4kFAl76U7oACgkQ5E+AFtNj
D4nrnRAArKd5ka3lsENoCZA7m4TTxEyitjnTqDsPNheuaJJloqjxULEQ6cYHwFiA
/uqxaHlAORwb3Mtu8nA69qv/yF68JNlAMNTWxsodhxmaAbejlaH/MRByOaCDdo4W
SmltjdHVUMWxGufv7NSI2VX7iduhRYy3cj0/uMViR900wx7oA2OlJSko6ykFlQCl
7XCDhrysfZoQh4JcLVelamaWOUA4SkVSoBn9v2ifqwIy9CAE97tG8SpQuzYDx/hM
rt7KFLjislbHyXE5vd0nAHTVT+vxcvlQizuxW0PrSKXWT/unjclUSVeG8ycbbPef
YDfwUK2MKiDda3zA+ifvoOHSC7/c0Lr6YxUoZkOdKj3Ky+IYyEkJuiP5gH7uxHpt
lT55Ow+rMNuONf+pOQK4I7rUx2FLd+U8ccEAy/xI9rE5yedC16afrx14uT+LOHyv
0B/5PkOLUxKZqz8nazStiAGIFNiLe7WK66ZRjryUJX4BrdF90JYFuHM24rfINlnu
NfAdLZ4Smh9LBDl10eyisocmDJCAkUeTY95hBzWNEtBvGnrbNVJjF71gtjmMYVfB
6zdNv9nkiI40FQ8tQ/AuAiXN+0IvN1ZRs5e4JE2dHYNW94DZW0m2Np+FbPqrWty+
9fSprHrZEL/UimRbzosaYKPgiwnaL8Nyli1+G3TyDZMO67eYfuE=
=fQ58
-----END PGP SIGNATURE-----

--=-7909yW7+UX5+hQaVXMcz--
0
john
6/29/2020 8:48:58 PM
> Sure, you could tell me that some company's internal code might have thei=
r own installation systems. Fine. They can either update their installation=
 software to emulate what the new tooling does or they can simply not upgra=
de Perl. I would bet that most shops actually use Perl's tooling, in which =
case they can just upgrade their Perl version and re-install.

Please try to see this problem outside the domain of "web development
is the only place perl gets used".

Because you just basically hit the same problem domain as "linux
vendors" (because vendor code doesn't use CPAN.pm or anything remotely
like that, and maintains a much firmer grip on what perl code can and
can't do inside their build chain). I hope you don't mind that linux
vendors may see this problem and not only not update perl, but also
not necessarily be overly keen on exposing their users to perl7 ( and
if they do, it will likely be in the form of dual-installation[1]
along-side perl5, where all the "serious business" continues to use
perl5 for system related tasks )

And linux vendors very much have to simply cope with 2 realities:
- Lots of perl code is in their workflow, which is NOT on CPAN,
because it's part of various opensource build chains. ( And this
oversight has in the past, broken autotools/friends of autotools with
simply "unescaped {" handling, yes, despite the fact there were
warnings for many years, because this very critical tool hadn't seen a
lot of upstream activity )
- Lots of users, who likely have their own little perl scripts for
various system tasks, who don't even participate in the general perl
ecosystem in a way you might ever see, and all these little perl
scripts are prone to become broken. ( Some of them may even just
inherit a system with such stuff, and have zero knowledge of how it
works, let alone, how to fix it when it breaks )

Yes,  all breakages and feature deprecations are subject to tripping
into this problem.

So the net result, whatever p5p does, the more that gets broken,
regardless *how* they break it, the predictable consequence is the
roll-out for linux vendors will be slower. And the slowness is
amplified as a function of how pervasive it already is.

So when you're trying to get brand new users into perl7, you'll really
have to make sure you continue to paper over the "what, why doesn't my
code work? Oh, so why is my system perl so ancient?" situation with
perl-brew and friends.

Is that a net benefit? I doubt it.

In short, I doubt the tooling changes will help vendors, even though
I'm yet to see how it is proposed to work exactly.

[1] And dual-installation is really not easy, especially if you even
anticipate dual-availability of all the supported CPAN modules on
*all* perl implementations on the target platform, because due to ABI
and XS constraints, one must compile each CPAN module independently on
each desired target perl implementation. If this was easy, we'd
already be supporting cperl and stableperl as well, but we aren't,
because the work is too much, and the amount of able bodies to make it
happen is too low, and to add to that, it grossly complicates the work
of the install chain, sometimes expressing that complexity as
user-facing problems and confusion. If my hand is forced on this
matter, perl7 will likely not be the only new target that gets some
love.





--=20
Kent

KENTNL - https://metacpan.org/author/KENTNL
0
kentfredric
6/29/2020 8:53:23 PM
--000000000000dc082e05a94103d7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

From https://www.youtube.com/watch?v=3D6wPMh-3qYJM:

we tried to write down all the things that we enable that to us is a good
> baseline for Perl. That list I think was around 8 to 10 lines.
>

It takes far more than that to write a portable script that handles STDIN,
STDOUT, STDERR and @ARGV correctly.

See https://www.perlmonks.org/?node_id=3D1231890 (and that still doesn't
handle @ARGV correctly on Windows).[1]

Sawyer X speaks of making it easy to accept newcomers, and I think one of
the biggest difficulties facing newcomers is dealing with encoding and
decoding. Did you know every single builtin function (named operator) that
deals with file names still suffers from The Unicode Bug?[2] And did you
know it's impossible to use the builtin functions to access files in
Windows?[3]

It seems to me this area would be a great area for improvement for Perl 8.
I've been tossing around plans for this in my head for a while, but
uncertainties in my life have detracted me from working on this.

- Eric "ikegami" Brine

1. Unless the command line happens to be limited to characters in the
intersection of the OEM Code Page character set and the Active Code Page
character set.
2. Demonstration found below.
3. Unless the file names happen to be limited to characters in the Active
Code Page character set.

$ perl -e'
   { my $f =3D chr(0xE9); utf8::downgrade($f); open(my $fh, ">", $f) or
warn($!); }
   { my $f =3D chr(0xE9); utf8::upgrade($f);   open(my $fh, ">", $f) or
warn($!); }
'

$ dir
total 0
-rw------- 1 ikegami ikegami 0 Jun 29 18:54 =C3=A9
-rw------- 1 ikegami ikegami 0 Jun 29 18:54 =EF=BF=BD

On Wed, Jun 24, 2020 at 4:49 PM Sawyer X <xsawyerx@gmail.com> wrote:

> Hi everyone,
>
> 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.
> * Major versions will be used for two purposes: 1. Turn on features
> and pragmas by default, 2. Remove syntax from the language.
> * Features will be guarded within a major version (that is, one *must*
> enable new features in 7.x with "use feature") but will be turned on
> in the next major version.
> * Perl 7.0.0 will be the first release. It will effectively be 5.32.0
> with a small number of pragmas (at the very least, strict and
> warnings) and features. The goal is to make it as trivial as possible
> to upgrade from 5.32.0 to 7.0.0.
> * Perl 5 will enter a long-term support window - 5+ years. Exact
> number not determined yet.
> * We intend to release 7.0.0 within a year. However, I am setting the
> goal of releasing it before the end of this year. I want to pave the
> way for 7.1.0, which will have the stable release of 7.2.0.
> * We will introduce utilities to help upgrade code to Perl 7. For
> example, if we were to add signatures by default in 7.0.0 (only *for
> example*), we will need code that helps users rewrite "sub foo ($)" as
> "sub foo :prototype($)".
> * We will also introduce a "compat::perl5" module, which will turn
> back the defaults of pragmas and features on 5.32.0. With this change,
> one could upgrade to Perl 7 binary immediately without changing the
> code. It allows a longer upgrade path.
> * We will also introduce a module to help fix up other modules. Such a
> module will especially help toolchain and infrastructure for CPAN
> manage the automatic upgrade or downgrade of modules without the user
> having to fix the code they are installing if it's incompatible.
>
> It would be hard to repeat everything in the talk, so I recommend
> watching the talk. The short and sweet is: We need to prioritize users
> who *write* Perl versus users who explicitly refuse or cannot update
> their code. In our current prioritization, we force all existing users
> and new users to manage the technical debt of previous generations.
>
> There is *a lot* to figure out at this point. We need to:
> * Update the internal code to support "use strict" and "use warnings".
> * Bump to 7.0.0.
> * Determine which pragmas and features will be enabled and turned on.
> * Determine how long we will support Perl version 5.
> * Determine the criteria for bumping major versions. Time might not be
> the best metric.
> * Create tickets for issues to be done so that the community could
> help. (People have already reached out, wanting to support this
> effort.)
> * Make sure we clarify what gets backported to Perl 5.32.x. Right now,
> it's the same criteria as every other maint release, except for a much
> longer time-frame.
> * Work on moving to 7.0.0 is already underway on the p7 branch here:
> https://github.com/atoomic/perl
>
> Additional comments:
> * Yearly releases for minor versions will continue as planned.
> * Monthly releases for dev versions will continue as planned.
> * See Perl 7.0.0 as 5.32.0 (+ some new defaults), 7.1.0 as 5.33.1.
> 7.2.0 will be akin to 5.34.0.
> * As exciting as 7.0.0 will be, it will mostly be there just to put us
> on our path. 8.0.0 will likely be much exciting.
> * There are notable stakeholders to the language which will be working
> with us to update their code to 7.0.0 defaults, to help understand the
> possible consequences.
> * We will need to rename the GitHub repo. That's okay because GitHub
> creates an automatic redirect for the URLs, including the GitHub clone
> paths.
> * /usr/bin/perl is owned by distributions. We are not in charge of it.
> We will be providing support to vendors and distributions and help
> them reach good decisions and move forward in the manner they choose.
>
> I apologize for not sharing this news earlier. We have been working on
> this plan for a very long time. p5p is a public mailing list, and we
> needed to manage the communication around this. Despite not being
> public, many people worked on it. Vital core developers, numerous core
> contributors, several significant stakeholders, vendors/distributions,
> and people with an in-depth history in Perl and the core code - were
> all involved. We have done a *lot* of work to get to where we are.
> While it's not a fully detailed change proposal, we have gone through
> quite a lot and tried to be very thorough while leaving room for
> things to now be openly discussed.
>
> Several threads will likely begin on the list to address specific
> issues listed above. I imagine this thread will itself receive a lot
> of responses and soon become sprawling. To manage this, I will open
> several threads, over several weeks, so we could have "waves" of
> discussions, instead of one monster thread in which we might quickly
> lose both our place and our focus. When discussing these topics, I
> request people to communicate mindfully and constructively.
>
> I want to thank everyone who helped work on this plan and shape it
> into what it is today. These are too many people to mention, but I
> want you to know I appreciate the effort, the time, the thorough
> reviews, the feedback, the ideas, and the solutions.
>
> Sawyer.
>
> [1] https://www.youtube.com/watch?v=3D6wPMh-3qYJM
>

--000000000000dc082e05a94103d7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">From <a href=3D"https://www.youtube.com/w=
atch?v=3D6wPMh-3qYJM">https://www.youtube.com/watch?v=3D6wPMh-3qYJM</a>:<br=
></div><div dir=3D"ltr"><br><div class=3D"gmail_quote"><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex">
we tried to write down all the things that we enable that to us is a good b=
aseline for Perl. That list I think was around 8 to 10 lines.

<br></blockquote></div><br>It takes far more than that to write a portable =
script that handles STDIN, STDOUT, STDERR and @ARGV correctly.<br><br>See <=
a href=3D"https://www.perlmonks.org/?node_id=3D1231890">https://www.perlmon=
ks.org/?node_id=3D1231890</a> (and that still doesn&#39;t handle @ARGV corr=
ectly on Windows).[1]<br><br>Sawyer X speaks of making it easy to accept ne=
wcomers, and I think one of the biggest difficulties facing newcomers is de=
aling with encoding and decoding. Did you know every single builtin functio=
n (named operator) that deals with file names still suffers from The Unicod=
e Bug?[2] And did you know it&#39;s impossible to use the builtin functions=
 to access files in Windows?[3]</div><div dir=3D"ltr"><br></div><div>It see=
ms to me this area would be a great area for improvement for Perl 8. I&#39;=
ve been tossing around plans for this in my head for a while, but uncertain=
ties in my life have detracted me from working on this.<br></div><div dir=
=3D"ltr"><br></div><div>- Eric &quot;ikegami&quot; Brine</div><div><br></di=
v><div dir=3D"ltr">1. Unless the command line happens to be limited to char=
acters in the intersection of the OEM Code Page character set and the Activ=
e Code Page character set.<br>
<div>2. Demonstration found below.<br></div>

3. Unless the file names happen to be limited to characters in the Active C=
ode Page character set.<br></div><div><br></div><div>$ perl -e&#39;<br>=C2=
=A0 =C2=A0{ my $f =3D chr(0xE9); utf8::downgrade($f); open(my $fh, &quot;&g=
t;&quot;, $f) or warn($!); }<br>=C2=A0 =C2=A0{ my $f =3D chr(0xE9); utf8::u=
pgrade($f); =C2=A0 open(my $fh, &quot;&gt;&quot;, $f) or warn($!); }<br>&#3=
9;<br><br>$ dir<br>total 0<br>-rw------- 1 ikegami ikegami 0 Jun 29 18:54 =
=C3=A9<br>-rw------- 1 ikegami ikegami 0 Jun 29 18:54 =EF=BF=BD</div><div><=
br></div><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">O=
n Wed, Jun 24, 2020 at 4:49 PM Sawyer X &lt;<a href=3D"mailto:xsawyerx@gmai=
l.com">xsawyerx@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex">Hi everyone,<br>
<br>
A little while ago, I gave a talk[1] at The Perl Conference in the<br>
Cloud where I covered the Plan for Perl that includes the following<br>
significant changes:<br>
<br>
* We will begin using major versions again, starting with version 7.<br>
* Major versions will be used for two purposes: 1. Turn on features<br>
and pragmas by default, 2. Remove syntax from the language.<br>
* Features will be guarded within a major version (that is, one *must*<br>
enable new features in 7.x with &quot;use feature&quot;) but will be turned=
 on<br>
in the next major version.<br>
* Perl 7.0.0 will be the first release. It will effectively be 5.32.0<br>
with a small number of pragmas (at the very least, strict and<br>
warnings) and features. The goal is to make it as trivial as possible<br>
to upgrade from 5.32.0 to 7.0.0.<br>
* Perl 5 will enter a long-term support window - 5+ years. Exact<br>
number not determined yet.<br>
* We intend to release 7.0.0 within a year. However, I am setting the<br>
goal of releasing it before the end of this year. I want to pave the<br>
way for 7.1.0, which will have the stable release of 7.2.0.<br>
* We will introduce utilities to help upgrade code to Perl 7. For<br>
example, if we were to add signatures by default in 7.0.0 (only *for<br>
example*), we will need code that helps users rewrite &quot;sub foo ($)&quo=
t; as<br>
&quot;sub foo :prototype($)&quot;.<br>
* We will also introduce a &quot;compat::perl5&quot; module, which will tur=
n<br>
back the defaults of pragmas and features on 5.32.0. With this change,<br>
one could upgrade to Perl 7 binary immediately without changing the<br>
code. It allows a longer upgrade path.<br>
* We will also introduce a module to help fix up other modules. Such a<br>
module will especially help toolchain and infrastructure for CPAN<br>
manage the automatic upgrade or downgrade of modules without the user<br>
having to fix the code they are installing if it&#39;s incompatible.<br>
<br>
It would be hard to repeat everything in the talk, so I recommend<br>
watching the talk. The short and sweet is: We need to prioritize users<br>
who *write* Perl versus users who explicitly refuse or cannot update<br>
their code. In our current prioritization, we force all existing users<br>
and new users to manage the technical debt of previous generations.<br>
<br>
There is *a lot* to figure out at this point. We need to:<br>
* Update the internal code to support &quot;use strict&quot; and &quot;use =
warnings&quot;.<br>
* Bump to 7.0.0.<br>
* Determine which pragmas and features will be enabled and turned on.<br>
* Determine how long we will support Perl version 5.<br>
* Determine the criteria for bumping major versions. Time might not be<br>
the best metric.<br>
* Create tickets for issues to be done so that the community could<br>
help. (People have already reached out, wanting to support this<br>
effort.)<br>
* Make sure we clarify what gets backported to Perl 5.32.x. Right now,<br>
it&#39;s the same criteria as every other maint release, except for a much<=
br>
longer time-frame.<br>
* Work on moving to 7.0.0 is already underway on the p7 branch here:<br>
<a href=3D"https://github.com/atoomic/perl" rel=3D"noreferrer" target=3D"_b=
lank">https://github.com/atoomic/perl</a><br>
<br>
Additional comments:<br>
* Yearly releases for minor versions will continue as planned.<br>
* Monthly releases for dev versions will continue as planned.<br>
* See Perl 7.0.0 as 5.32.0 (+ some new defaults), 7.1.0 as 5.33.1.<br>
7.2.0 will be akin to 5.34.0.<br>
* As exciting as 7.0.0 will be, it will mostly be there just to put us<br>
on our path. 8.0.0 will likely be much exciting.<br>
* There are notable stakeholders to the language which will be working<br>
with us to update their code to 7.0.0 defaults, to help understand the<br>
possible consequences.<br>
* We will need to rename the GitHub repo. That&#39;s okay because GitHub<br=
>
creates an automatic redirect for the URLs, including the GitHub clone<br>
paths.<br>
* /usr/bin/perl is owned by distributions. We are not in charge of it.<br>
We will be providing support to vendors and distributions and help<br>
them reach good decisions and move forward in the manner they choose.<br>
<br>
I apologize for not sharing this news earlier. We have been working on<br>
this plan for a very long time. p5p is a public mailing list, and we<br>
needed to manage the communication around this. Despite not being<br>
public, many people worked on it. Vital core developers, numerous core<br>
contributors, several significant stakeholders, vendors/distributions,<br>
and people with an in-depth history in Perl and the core code - were<br>
all involved. We have done a *lot* of work to get to where we are.<br>
While it&#39;s not a fully detailed change proposal, we have gone through<b=
r>
quite a lot and tried to be very thorough while leaving room for<br>
things to now be openly discussed.<br>
<br>
Several threads will likely begin on the list to address specific<br>
issues listed above. I imagine this thread will itself receive a lot<br>
of responses and soon become sprawling. To manage this, I will open<br>
several threads, over several weeks, so we could have &quot;waves&quot; of<=
br>
discussions, instead of one monster thread in which we might quickly<br>
lose both our place and our focus. When discussing these topics, I<br>
request people to communicate mindfully and constructively.<br>
<br>
I want to thank everyone who helped work on this plan and shape it<br>
into what it is today. These are too many people to mention, but I<br>
want you to know I appreciate the effort, the time, the thorough<br>
reviews, the feedback, the ideas, and the solutions.<br>
<br>
Sawyer.<br>
<br>
[1] <a href=3D"https://www.youtube.com/watch?v=3D6wPMh-3qYJM" rel=3D"norefe=
rrer" target=3D"_blank">https://www.youtube.com/watch?v=3D6wPMh-3qYJM</a><b=
r>
</blockquote></div></div>

--000000000000dc082e05a94103d7--
0
ikegami
6/29/2020 10:59:33 PM
--000000000000225cf705a941271c
Content-Type: text/plain; charset="UTF-8"

On Sat, Jun 27, 2020 at 12:46 PM Dan Book <grinnz@gmail.com> wrote:

> unicode_strings causes a specific set of functions in that lexical scope
> to use Unicode rules when determining how they interact with a string,
> instead of possibly using ASCII rules if the string is downgraded as the
> previous heuristic did.
>

Or put otherwise, it simply fixes a handful of builtin functions that
otherwise suffer from The Unicode Bug (behave differently depending on the
internal storage format of the their input).

--000000000000225cf705a941271c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail=
_attr">On Sat, Jun 27, 2020 at 12:46 PM Dan Book &lt;<a href=3D"mailto:grin=
nz@gmail.com">grinnz@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex"><div dir=3D"ltr">unicode_strings causes a spe=
cific set of functions in that lexical scope to use Unicode rules when dete=
rmining how they interact with a string, instead of possibly using ASCII ru=
les if the string is downgraded as the previous heuristic did.</div></block=
quote><div><br></div><div>Or put otherwise, it simply fixes a handful of bu=
iltin functions that otherwise suffer from The Unicode Bug (behave differen=
tly depending on the internal storage format of the their input).<br></div>=
<br></div></div>

--000000000000225cf705a941271c--
0
ikegami
6/29/2020 11:09:26 PM
--00000000000088596205a9413fab
Content-Type: text/plain; charset="UTF-8"

On Sun, Jun 28, 2020 at 1:23 PM Christian Walde <walde.christian@gmail.com>
wrote:

> On Fri, 26 Jun 2020 20:57:39 +0200, John Lightsey <john@nixnuts.net>
> wrote:
>
> > I'd love to see Perl 8 fix [...] Windows support.
>
> 2 things here:
>
> 1. Please don't phrase it in a way that implies Perl doesn't support
> windows. I've been developing Perl on windows for over a decade and it
> works.
>
> 2. Out of curiosity, what specific points do you care about here?


A major one is the inability to use builtin functions (named operators) to
work with files. Only file names formed from characters from the Active
Code Page can be passed to/received from functions (e.g. open, readdir,
stat).

--00000000000088596205a9413fab
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"g=
mail_attr">On Sun, Jun 28, 2020 at 1:23 PM Christian Walde &lt;<a href=3D"m=
ailto:walde.christian@gmail.com">walde.christian@gmail.com</a>&gt; wrote:<b=
r></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, 26 Jun 20=
20 20:57:39 +0200, John Lightsey &lt;<a href=3D"mailto:john@nixnuts.net" ta=
rget=3D"_blank">john@nixnuts.net</a>&gt; wrote:<br>
<br>
&gt; I&#39;d love to see Perl 8 fix [...] Windows support.<br>
<br>
2 things here:<br>
<br>
1. Please don&#39;t phrase it in a way that implies Perl doesn&#39;t suppor=
t windows. I&#39;ve been developing Perl on windows for over a decade and i=
t works.<br>
<br>
2. Out of curiosity, what specific points do you care about here?</blockquo=
te><div><br></div><div>A major one is the inability to use builtin function=
s (named operators) to work with files. Only file names formed from charact=
ers from the Active Code Page can be passed to/received from functions (e.g=
.. open, readdir, stat).</div><div></div><div><br></div><div><br></div><div>=
=C2=A0</div></div></div>

--00000000000088596205a9413fab--
0
ikegami
6/29/2020 11:16:15 PM
> On Jun 29, 2020, at 6:59 PM, Eric Brine <ikegami@adaelis.com> wrote:
>=20
> Sawyer X speaks of making it easy to accept newcomers, and I think one =
of the biggest difficulties facing newcomers is dealing with encoding =
and decoding.

I know seasoned Perl developers who struggle with Perl=E2=80=99s =
character encoding logic. Until embarrassingly-recently I was one of =
them, and I=E2=80=99m still a bit nervous to claim I now understand it.

It *IS* fairly simple, I think, once the crucial pieces =E2=80=9Cclick=E2=80=
=9D mentally. But that =E2=80=9Cclick=E2=80=9D is, IMO, far from =
=E2=80=9Cdefault=E2=80=9D. And, like reference-counting in C, it=E2=80=99s=
 fiendishly easy to make a subtle mistake that may not manifest until =
you=E2=80=99re far removed from the context where the bug is.

Perl=E2=80=99s =E2=80=9Chappy confusion=E2=80=9D between =
character-vs.-byte strings is a stumbling block for so many. It =
aggravates the learning curve for newcomers and complicates IPC with =
other languages. If we could somehow have =E2=80=9Cintrospectable=E2=80=9D=
 string types--strings that =E2=80=9Cknow=E2=80=9D whether they =
represent octets or characters--I think that would be a boon for =
everyone.

-FG=
0
felipe
6/29/2020 11:46:54 PM
--0000000000005da14c05a941bde4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Jun 29, 2020 at 7:46 PM Felipe Gasper <felipe@felipegasper.com>
wrote:

>
> > On Jun 29, 2020, at 6:59 PM, Eric Brine <ikegami@adaelis.com> wrote:
> >
> > Sawyer X speaks of making it easy to accept newcomers, and I think one
> of the biggest difficulties facing newcomers is dealing with encoding and
> decoding.
>
> I know seasoned Perl developers who struggle with Perl=E2=80=99s characte=
r
> encoding logic. Until embarrassingly-recently I was one of them, and I=E2=
=80=99m
> still a bit nervous to claim I now understand it.
>
> It *IS* fairly simple, I think, once the crucial pieces =E2=80=9Cclick=E2=
=80=9D mentally.
> But that =E2=80=9Cclick=E2=80=9D is, IMO, far from =E2=80=9Cdefault=E2=80=
=9D. And, like reference-counting
> in C, it=E2=80=99s fiendishly easy to make a subtle mistake that may not =
manifest
> until you=E2=80=99re far removed from the context where the bug is.
>
> Perl=E2=80=99s =E2=80=9Chappy confusion=E2=80=9D between character-vs.-by=
te strings is a stumbling
> block for so many. It aggravates the learning curve for newcomers and
> complicates IPC with other languages. If we could somehow have
> =E2=80=9Cintrospectable=E2=80=9D string types--strings that =E2=80=9Cknow=
=E2=80=9D whether they represent
> octets or characters--I think that would be a boon for everyone.


100% agreed. I plan to write a blog post at some point on how strings work
in Perl currently but a feature that allows one to declare explicit
intentions as magic attached to strings would be the beginnings of a very
useful system to help people who don't understand the setup or how one
should approach character encoding, and as you mentioned this is far from
just Perl newcomers.

-Dan

--0000000000005da14c05a941bde4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Mon, Jun 29, 2020 at 7:46 PM Felipe Ga=
sper &lt;<a href=3D"mailto:felipe@felipegasper.com">felipe@felipegasper.com=
</a>&gt; wrote:<br></div><div class=3D"gmail_quote"><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,=
204,204);padding-left:1ex"><br>
&gt; On Jun 29, 2020, at 6:59 PM, Eric Brine &lt;<a href=3D"mailto:ikegami@=
adaelis.com" target=3D"_blank">ikegami@adaelis.com</a>&gt; wrote:<br>
&gt; <br>
&gt; Sawyer X speaks of making it easy to accept newcomers, and I think one=
 of the biggest difficulties facing newcomers is dealing with encoding and =
decoding.<br>
<br>
I know seasoned Perl developers who struggle with Perl=E2=80=99s character =
encoding logic. Until embarrassingly-recently I was one of them, and I=E2=
=80=99m still a bit nervous to claim I now understand it.<br>
<br>
It *IS* fairly simple, I think, once the crucial pieces =E2=80=9Cclick=E2=
=80=9D mentally. But that =E2=80=9Cclick=E2=80=9D is, IMO, far from =E2=80=
=9Cdefault=E2=80=9D. And, like reference-counting in C, it=E2=80=99s fiendi=
shly easy to make a subtle mistake that may not manifest until you=E2=80=99=
re far removed from the context where the bug is.<br>
<br>
Perl=E2=80=99s =E2=80=9Chappy confusion=E2=80=9D between character-vs.-byte=
 strings is a stumbling block for so many. It aggravates the learning curve=
 for newcomers and complicates IPC with other languages. If we could someho=
w have =E2=80=9Cintrospectable=E2=80=9D string types--strings that =E2=80=
=9Cknow=E2=80=9D whether they represent octets or characters--I think that =
would be a boon for everyone.</blockquote><div><br></div><div>100% agreed. =
I plan to write a blog post at some point on how strings work in Perl curre=
ntly but a feature that allows one to declare explicit intentions as magic =
attached to strings would be the beginnings of a very useful system to help=
 people who don&#39;t understand the=C2=A0setup or how one should approach =
character encoding, and as you mentioned this is far from just Perl newcome=
rs.</div><div><br></div><div>-Dan</div></div></div>

--0000000000005da14c05a941bde4--
0
grinnz
6/29/2020 11:51:12 PM
On Mon, Jun 29, 2020 at 3:54 PM Kent Fredric <kentfredric@gmail.com> wrote:

> the net result, whatever p5p does

For the record, p5p has nothing to do with it.  The public mailing
list appears to have been carefully and intentionally excluded from
the first few months of Perl 7 development, and there have been very
few and very incomplete and inconsistent replies here to the many
questions and objections raised, and no response at all to a number of
suggested modifications to the proposal that would make implementation
of the stated goals saner and more achievable.

>, the more that gets broken,
> regardless *how* they break it, the predictable consequence is the
> roll-out for linux vendors will be slower.

Or, presumably, not at all.  I can't imagine why a Linux vendor would
add yet another package, among all the projects out there vying for
attention, that doesn't do anything they need or want and breaks all
the existing Perl code upon which they rely.
0
craig
6/30/2020 2:50:39 AM
On 2020-06-29 4:51 p.m., Dan Book wrote:
> On Mon, Jun 29, 2020 at 7:46 PM Felipe Gasper wrote:
>     Perl’s “happy confusion” between character-vs.-byte strings is a stumbling
>     block for so many. It aggravates the learning curve for newcomers and
>     complicates IPC with other languages. If we could somehow have
>     “introspectable” string types--strings that “know” whether they represent
>     octets or characters--I think that would be a boon for everyone.
> 
> 100% agreed. I plan to write a blog post at some point on how strings work in 
> Perl currently but a feature that allows one to declare explicit intentions as 
> magic attached to strings would be the beginnings of a very useful system to 
> help people who don't understand the setup or how one should approach character 
> encoding, and as you mentioned this is far from just Perl newcomers.

I feel it would be a great boon if Perl made the waters less muddy with respect 
to easily knowing what kind of scalar you have.

As far as I know, there are at least 4 distinct things that a non-reference Perl 
scalar may represent:

- An integer, meaning an IV.
- A floating-point number, meaning an FV.
- A string of octets, meaning one kind of SV.
- A string of characters, meaning a different kind of SV.

I for one would love to have a very easy way to introspect, in a very strict 
manner, exactly which one of these 4 we have.

Ideally there would be a disjoint representation of a pure boolean as well, that 
is distinct from 0 or 1 or "" or so on, like any other good modern language has.

A key business requirement I have is that I can write code that takes a generic 
Perl scalar as input and do different things depending on which type it is in 
the strict sense, because it can distinguish them without any extra metadata not 
in the scalar itself.  I can workaround gaps in this by supplying metadata 
externally, but that is a more verbose and slower user experience than it being 
natively part of Perl scalars.

-- Darren Duncan
0
darren
6/30/2020 3:54:50 AM
Having taken more time to think about this, and seeing more discussion, I have 
come around further towards supporting a key aspect of Sawyer's proposal.

1. I no longer believe that a v7+ Perl interpreter should consider it mandatory 
for each Perl file to start with a "use <version>;" and instead I take the 
position that using such declarations should just be strongly encouraged, 
particularly for any Perl code meant to be shared with others.

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.

3. I still think the long-existing way of declaring versions should continue to 
be used as THE way to distinguish Perl 5 from 7+, such as "use 5.012;" or "use 
7.0;", and that "use compat::Perl5" or whatever is an inferior option.  When we 
have explicit markers we want it to be something older Perl will do the right 
thing with.

This way, the simplest and private use cases of Perl would have no explicit 
versions, and one starts using explicit versions as a recommended best practice 
once code becomes non-trivial in size or is intended to be shared with others, 
including everything published on CPAN.

I still think we should not be trying to discourage explicit version markers; 
their use should still be encouraged, but maybe just isn't one of the first 
things you tell a new user, and include it in what you tell them when you say, 
okay you want to share your code with others, this will make that work better.

-- Darren Duncan

On 2020-06-28 6:05 p.m., Darren Duncan wrote:
> I feel the best all-around solution here is for the Perl interpreter as of 
> version 7.0.0 to make it mandatory to have the "use N;" (where N is a version 
> number) tiny boilerplate at the top of each Perl file it runs.
> 
> This boilerplate has the same meaning it always had but it is now mandatory 
> rather than optional.
> 
> This simple solution is a have our cake and eat it too thing.
> 
> By forcing a declaration, authors explicitly say what baseline behavior that 
> they expect, and that can either be 5 or 7, but they say it explicitly.
> 
> Then the discussion is no longer the contentious what do you get when no version 
> is specified, but rather what reasonable action does the Perl 7+ interpreter 
> take when encountering a particular version declaration.  Most of the discussion 
> here then is that the default behavior of Perl interpreter 7 is what happens 
> when "use 7" is in a file.
> 
> Perl 5 code with appropriate "use 5" will continue to behave as it did before 
> under a Perl 5 interpreter, and the Perl 7 interpreter will also permit it to 
> run, and know what is expected.
> 
> The Perl 7+ interpreters can still remove older features so that certain Perl 5 
> code will no longer run, but in that case they can separately give the error 
> that eg 5.6 behavior is not supported, and the error can be customized based on 
> the file's declared version that indicated what the author expected.
> 
> See https://www.nntp.perl.org/group/perl.perl5.porters/2020/06/msg257607.html 
> where I previously talked about this at greater length.  I'm saying this again 
> as I feel my prior message may not have been seen in the haystack or because I 
> wasn't subscribed to the list then but now I am.
> 
> If we simply get away from the idea that Perl is best without any version 
> declaration at all, the better off we'll be.
> 
> -- Darren Duncan
0
darren
6/30/2020 4:40:39 AM
--0000000000004d275f05a9465d74
Content-Type: text/plain; charset="UTF-8"

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!

--0000000000004d275f05a9465d74
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"></div><br><div class=3D"gmail_quote"><div=
 dir=3D"ltr" class=3D"gmail_attr">On Tue, 30 Jun 2020 at 12:40, Darren Dunc=
an &lt;<a href=3D"mailto:darren@darrenduncan.net">darren@darrenduncan.net</=
a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">2.=
 I also completely agree that IF Perl code lacks an explicit version marker=
, <br>
then a v7+ Perl interpreter should indeed interpret it as the latest versio=
n of <br>
Perl it understands implicitly, rather than interpreting it as Perl 5.0.0.<=
br></blockquote><div><br></div>Just to put a few numbers to this...</div><d=
iv class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">There are at =
least 757 distributions on CPAN that would break due to signatures being en=
abled:<br></div><div class=3D"gmail_quote"><div><br></div><div><a href=3D"h=
ttps://grep.metacpan.org/search?size=3D20&amp;q=3D%5Esub+%5Cw%2B%5C%28%26&a=
mp;qd=3D&amp;qft=3D">https://grep.metacpan.org/search?size=3D20&amp;q=3D%5E=
sub+%5Cw%2B%5C%28%26&amp;qd=3D&amp;qft=3D</a><br></div><div><br></div><div>=
Some of them - AnyEvent, for example - are likely to encounter, ah... &quot=
;political issues&quot; (see the fallout from sort-in-place hidden feature =
for reference).</div><div><br></div><div>There are at least 150 distributio=
ns which would break, or at least have misleading documentation, if `no ind=
irect` becomes default:</div><div><br></div><div><a href=3D"https://grep.me=
tacpan.org/search?q=3D%3D+new+%5BA-Z%5D&amp;qd=3D&amp;qft=3D">https://grep.=
metacpan.org/search?q=3D%3D+new+%5BA-Z%5D&amp;qd=3D&amp;qft=3D</a><br></div=
><div><br></div><div>That&#39;s a low estimate, the search timed out and th=
ere are likely many other variants of indirect syntax.</div><div><br></div>=
<div>So one concern that does not seem to have been addressed by the &quot;=
enable by default&quot; proposal is &quot;what about CPAN&quot;. It used to=
 be a selling point for Perl, would be a shame to lose that.</div><div><br>=
</div><div>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:</div>=
<div><br></div><div>- anyone who has existing Perl code</div><div>- new dev=
elopers who hear about CPAN and would like to use it in their new code</div=
><div><br></div><div>That second group may lose some enthusiasm if they kee=
p running into modules that don&#39;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.</div><div><br></div><div>Don&=
#39;t take anyone&#39;s word for this, though - give it a try yourself!</di=
v><div><br></div><div>Here&#39;s a script that should work as a starting po=
int to identify &quot;does this CPAN module break&quot;:</div><div><br></di=
v><div>perl -e&#39;BEGIN { @INC =3D (sub { my ($path) =3D grep { &quot;$_&q=
uot;; -e $_ &amp;&amp; !-d _ &amp;&amp; !-b _ } map { &quot;$_/$_[1]&quot; =
} grep { !ref } @INC; open my $fh, &quot;&lt;&quot;, $path or die $!; retur=
n \&quot;use strict qw(vars subs); no indirect; use utf8; use feature qw(si=
gnatures); use warnings; &quot;, $fh }, @INC); } eval &quot;require $_&quot=
; or die $@ for @ARGV&#39; List::UtilsBy<br></div><div><br></div><div>Note =
that we can&#39;t start with `use strict`, because many of the core modules=
 would fail with that in force. I suspect it&#39;s also not a complete list=
 of the proposed v7 directives. The main failure with this example (List::U=
tilsBy) is related to signatures - but I would suggest that testing it out =
on the dependencies that you&#39;re using in real code, seems that would gi=
ve useful data points for the discussion?</div><div><br></div><div>I can&#3=
9;t immediately see how this amount of breakage could be resolved without s=
ome discomforting workarounds (&quot;old defaults for installed modules or =
internal @INC paths, new defaults for app code and PERL5LIB additions&quot;=
) or putting `use v7;` or equivalent in new code. Of course, this is just a=
 failure of imagination on my part - the Pumpking=C2=A0doubtless=C2=A0has s=
ome magic up his sleeve that will put these concerns to rest!</div></div></=
div>

--0000000000004d275f05a9465d74--
0
perl5
6/30/2020 5:22:30 AM
On 2020-06-29 10:22 p.m., Tom Molesworth via perl5-porters wrote:
> 
> On Tue, 30 Jun 2020 at 12:40, Darren Duncan 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.
> 
> 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.

Well I DID say that CPAN is one of those places where explicit versions SHOULD 
be used.  And if any don't, well CPAN is public, and as you demonstrated we can 
see what would break.  And so we now are in the position to fix those modules.

> 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?

Well the Perl core certainly should be dogfooding this.  Whatever decision is 
made should apply the same to the core, and if the core needs updating for 
compatibility, then it gets updated before v7 of the interpreter is released.

A key pre-condition for Perl 7+ being released publicly is that both its bundled 
core modules are compatible and also the most heavily used and most upriver 
parts of CPAN are compatible, and the greater fraction the better.

-- Darren Duncan
0
darren
6/30/2020 5:33:11 AM
--000000000000ce1ab305a9469ebc
Content-Type: text/plain; charset="UTF-8"

On Tue, 30 Jun 2020 at 13:33, Darren Duncan <darren@darrenduncan.net> wrote:

> On 2020-06-29 10:22 p.m., Tom Molesworth via perl5-porters wrote:
> > 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.
>
> Well I DID say that CPAN is one of those places where explicit versions
> SHOULD
> be used.  And if any don't, well CPAN is public, and as you demonstrated
> we can
> see what would break.  And so we now are in the position to fix those
> modules.
>

Fix... how? They aren't broken until we change the rules, some of them
haven't had a release in years, and are you suggesting that p5p takes
responsibility for unilaterally releasing patched versions? Ignoring
licenses and any other concerns, seems like a lot of work - and that hasn't
even happened in the past for dual-life modules, look at the cases where
*core Perl* releases with "development versions" of important modules
because there's a patch that is not yet on CPAN. Have a look at the
Scalar-List-Utils sorting discussion from not too long ago - even when
there's a working patch, it's not always trivial to ensure that it makes it
into a stable release.

With limited available resources, and a long list of things to be done -
many of which are the subject of separate threads which haven't even
started yet - it would seem safer to avoid a big "release all the modules"
project. Maybe some more advanced patching option is something that the
toolchain is already working on...

--000000000000ce1ab305a9469ebc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Tue, 30 Jun 2020 at 13:33, Darren =
Duncan &lt;<a href=3D"mailto:darren@darrenduncan.net">darren@darrenduncan.n=
et</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
">On 2020-06-29 10:22 p.m., Tom Molesworth via perl5-porters wrote:<br>&gt;=
 So one concern that does not seem to have been addressed by the &quot;enab=
le by <br>
&gt; default&quot; proposal is &quot;what about CPAN&quot;. It used to be a=
 selling point for Perl, <br>
&gt; would be a shame to lose that.<br>
<br>
Well I DID say that CPAN is one of those places where explicit versions SHO=
ULD <br>
be used.=C2=A0 And if any don&#39;t, well CPAN is public, and as you demons=
trated we can <br>
see what would break.=C2=A0 And so we now are in the position to fix those =
modules.<br></blockquote><div><br></div><div>Fix... how? They aren&#39;t br=
oken until we change the rules, some of them haven&#39;t had a release in y=
ears, and are you suggesting that p5p takes responsibility for unilaterally=
 releasing patched versions? Ignoring licenses and any other concerns, seem=
s like a lot of work - and that hasn&#39;t even happened in the past for du=
al-life modules, look at the cases where *core Perl* releases with &quot;de=
velopment versions&quot; of important modules because there&#39;s a patch t=
hat is not yet on CPAN. Have a look at the Scalar-List-Utils sorting discus=
sion from not too long ago - even when there&#39;s a working patch, it&#39;=
s not always trivial to ensure that it makes it into a stable release.</div=
><div><br></div><div>With limited available resources, and a long list of t=
hings to be done - many of which are the subject of separate threads which =
haven&#39;t even started yet - it would seem safer to avoid a big &quot;rel=
ease all the modules&quot; project. Maybe some more advanced patching optio=
n is something that the toolchain is already working on...</div><div><br></=
div></div></div>

--000000000000ce1ab305a9469ebc--
0
perl5
6/30/2020 5:40:49 AM
On 2020-06-29 10:40 p.m., Tom Molesworth wrote:
> On Tue, 30 Jun 2020 at 13:33, Darren Duncan wrote:
> 
>     On 2020-06-29 10:22 p.m., Tom Molesworth via perl5-porters wrote:
>      > 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.
> 
>     Well I DID say that CPAN is one of those places where explicit versions SHOULD
>     be used.  And if any don't, well CPAN is public, and as you demonstrated we can
>     see what would break.  And so we now are in the position to fix those modules.
> 
> Fix... how? They aren't broken until we change the rules, some of them haven't 
> had a release in years, and are you suggesting that p5p takes responsibility for 
> unilaterally releasing patched versions? Ignoring licenses and any other 
> concerns, seems like a lot of work - and that hasn't even happened in the past 
> for dual-life modules, look at the cases where *core Perl* releases with 
> "development versions" of important modules because there's a patch that is not 
> yet on CPAN. Have a look at the Scalar-List-Utils sorting discussion from not 
> too long ago - even when there's a working patch, it's not always trivial to 
> ensure that it makes it into a stable release.
> 
> With limited available resources, and a long list of things to be done - many of 
> which are the subject of separate threads which haven't even started yet - it 
> would seem safer to avoid a big "release all the modules" project. Maybe some 
> more advanced patching option is something that the toolchain is already working 
> on...

Fix means make compatible.  And the argument is for the community at large to do 
it, not just those who maintain the Perl interpreter.

I recall various comments that the Perl 7 announcement has lit a fire under the 
wider Perl community and a lot of people are chomping at the bit to help the 
effort.  Well providing compatibility updates to modules is a good use of that.

Lots of modules are in public version control and people wanting to help can 
submit pull requests for them.  This has happened over the years anyway.

A low-hanging fruit is that if anything doesn't work with use strict it is 
updated to declare its variables and so on.

Personally I do NOT advocate that signatures or anything likely to change be 
turned on by default, but simpler things unlikely to change should be like "say".

-- Darren Duncan
0
darren
6/30/2020 6:00:29 AM

> On Jun 28, 2020, at 7:33 AM, Andreas Koenig =
<andreas.koenig.7os6VVqR@franz.ak.mind.de> wrote:
>=20
>>>>>> On Sun, 28 Jun 2020 03:39:52 -0500, Todd Rinaldo =
<toddr@cpanel.net> said:
>=20
>>> On Jun 28, 2020, at 2:38 AM, Paul LeoNerd Evans =
<leonerd@leonerd.org.uk> wrote:
>>>=20
>>> If `try` syntax becomes default - probably not in 7 but maybe in 8 -
>>> then how is perltidy going to know how to properly format and indent
>>> this, and all the other exciting syntax we hope to have in place by =
8?
>>>=20
>=20
>> Easily. They check $].
>=20
> Hi Todd,
>=20
> this does not work. For example, see here is a line of perl code:
>=20
>  print "Hello, Rinaldo";
>=20
> So what is $] in this line and how do you find out? If you simply run
> it, you make a decision, with which interpreter you start it. And =
hereby
> you influence the outcome for $]. So: the value of $] is a result of
> your decision, not something intrinsic to the code.
>=20
> --=20
> andreas

My suggestion was that the version of perl critic runs under should =
dictate how it behaves.=20=
0
toddr
6/30/2020 6:32:43 AM
--Apple-Mail=_B2BE51C3-11C6-451B-B588-CF932135C0FB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii



> On Jun 28, 2020, at 8:00 PM, Dan Book <grinnz@gmail.com> wrote:
>=20
> To start with, having installers inject code into CPAN modules is both =
a licensing and technical issue. The artistic license does not permit =
modifying the code without changing the name. Injecting code changes =
line numbers from what you find on CPAN. Can these be solved? Perhaps, =
but not without discussing these things.

Are you suggesting that changing the #! at the top of installed perl =
files (which we already do) is a license violation?

Todd


--Apple-Mail=_B2BE51C3-11C6-451B-B588-CF932135C0FB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;" class=3D""><br =
class=3D""><div><br class=3D""><blockquote type=3D"cite" class=3D""><div =
class=3D"">On Jun 28, 2020, at 8:00 PM, Dan Book &lt;<a =
href=3D"mailto:grinnz@gmail.com" class=3D"">grinnz@gmail.com</a>&gt; =
wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><span =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none; float: none; =
display: inline !important;" class=3D"">To start with, having installers =
inject code into CPAN modules is both a licensing and technical issue. =
The artistic license does not permit modifying the code without changing =
the name. Injecting code changes line numbers from what you find on =
CPAN. Can these be solved? Perhaps, but not without discussing these =
things.</span></div></blockquote></div><br class=3D""><div class=3D"">Are =
you suggesting that changing the #! at the top of installed perl files =
(which we already do) is a license violation?</div><div class=3D""><br =
class=3D""></div><div class=3D"">Todd</div><div class=3D""><br =
class=3D""></div></body></html>=

--Apple-Mail=_B2BE51C3-11C6-451B-B588-CF932135C0FB--
0
toddr
6/30/2020 6:38:29 AM
--000000000000d1d3d405a94772d0
Content-Type: text/plain; charset="UTF-8"

On Tue, Jun 30, 2020 at 2:00 AM Darren Duncan <darren@darrenduncan.net>
wrote:

> On 2020-06-29 10:40 p.m., Tom Molesworth wrote:
> > On Tue, 30 Jun 2020 at 13:33, Darren Duncan wrote:
> >
> >     On 2020-06-29 10:22 p.m., Tom Molesworth via perl5-porters wrote:
> >      > 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.
> >
> >     Well I DID say that CPAN is one of those places where explicit
> versions SHOULD
> >     be used.  And if any don't, well CPAN is public, and as you
> demonstrated we can
> >     see what would break.  And so we now are in the position to fix
> those modules.
> >
> > Fix... how? They aren't broken until we change the rules, some of them
> haven't
> > had a release in years, and are you suggesting that p5p takes
> responsibility for
> > unilaterally releasing patched versions? Ignoring licenses and any other
> > concerns, seems like a lot of work - and that hasn't even happened in
> the past
> > for dual-life modules, look at the cases where *core Perl* releases with
> > "development versions" of important modules because there's a patch that
> is not
> > yet on CPAN. Have a look at the Scalar-List-Utils sorting discussion
> from not
> > too long ago - even when there's a working patch, it's not always
> trivial to
> > ensure that it makes it into a stable release.
> >
> > With limited available resources, and a long list of things to be done -
> many of
> > which are the subject of separate threads which haven't even started yet
> - it
> > would seem safer to avoid a big "release all the modules" project. Maybe
> some
> > more advanced patching option is something that the toolchain is already
> working
> > on...
>
> Fix means make compatible.  And the argument is for the community at large
> to do
> it, not just those who maintain the Perl interpreter.
>
> I recall various comments that the Perl 7 announcement has lit a fire
> under the
> wider Perl community and a lot of people are chomping at the bit to help
> the
> effort.  Well providing compatibility updates to modules is a good use of
> that.
>
> Lots of modules are in public version control and people wanting to help
> can
> submit pull requests for them.  This has happened over the years anyway.
>
> A low-hanging fruit is that if anything doesn't work with use strict it is
> updated to declare its variables and so on.
>
> Personally I do NOT advocate that signatures or anything likely to change
> be
> turned on by default, but simpler things unlikely to change should be like
> "say".
>

I am just going to say, I think you have not been paying attention to many
of the attempts to do things just like this on CPAN previously if you think
this is attainable, nevermind easy. We are still trying to get rid of
problematic uses of Module::Install to this day.

-Dan

--000000000000d1d3d405a94772d0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Tue, Jun 30, 2020 at 2:00 AM Darren Du=
ncan &lt;<a href=3D"mailto:darren@darrenduncan.net">darren@darrenduncan.net=
</a>&gt; wrote:<br></div><div class=3D"gmail_quote"><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,=
204,204);padding-left:1ex">On 2020-06-29 10:40 p.m., Tom Molesworth wrote:<=
br>
&gt; On Tue, 30 Jun 2020 at 13:33, Darren Duncan wrote:<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0On 2020-06-29 10:22 p.m., Tom Molesworth via perl5-=
porters wrote:<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; So one concern that does not seem to have bee=
n addressed by the &quot;enable by<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; default&quot; proposal is &quot;what about CP=
AN&quot;. It used to be a selling point for<br>
&gt;=C2=A0 =C2=A0 =C2=A0Perl,<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; would be a shame to lose that.<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0Well I DID say that CPAN is one of those places whe=
re explicit versions SHOULD<br>
&gt;=C2=A0 =C2=A0 =C2=A0be used.=C2=A0 And if any don&#39;t, well CPAN is p=
ublic, and as you demonstrated we can<br>
&gt;=C2=A0 =C2=A0 =C2=A0see what would break.=C2=A0 And so we now are in th=
e position to fix those modules.<br>
&gt; <br>
&gt; Fix... how? They aren&#39;t broken until we change the rules, some of =
them haven&#39;t <br>
&gt; had a release in years, and are you suggesting that p5p takes responsi=
bility for <br>
&gt; unilaterally releasing patched versions? Ignoring licenses and any oth=
er <br>
&gt; concerns, seems like a lot of work - and that hasn&#39;t even happened=
 in the past <br>
&gt; for dual-life modules, look at the cases where *core Perl* releases wi=
th <br>
&gt; &quot;development versions&quot; of important modules because there&#3=
9;s a patch that is not <br>
&gt; yet on CPAN. Have a look at the Scalar-List-Utils sorting discussion f=
rom not <br>
&gt; too long ago - even when there&#39;s a working patch, it&#39;s not alw=
ays trivial to <br>
&gt; ensure that it makes it into a stable release.<br>
&gt; <br>
&gt; With limited available resources, and a long list of things to be done=
 - many of <br>
&gt; which are the subject of separate threads which haven&#39;t even start=
ed yet - it <br>
&gt; would seem safer to avoid a big &quot;release all the modules&quot; pr=
oject. Maybe some <br>
&gt; more advanced patching option is something that the toolchain is alrea=
dy working <br>
&gt; on...<br>
<br>
Fix means make compatible.=C2=A0 And the argument is for the community at l=
arge to do <br>
it, not just those who maintain the Perl interpreter.<br>
<br>
I recall various comments that the Perl 7 announcement has lit a fire under=
 the <br>
wider Perl community and a lot of people are chomping at the bit to help th=
e <br>
effort.=C2=A0 Well providing compatibility updates to modules is a good use=
 of that.<br>
<br>
Lots of modules are in public version control and people wanting to help ca=
n <br>
submit pull requests for them.=C2=A0 This has happened over the years anywa=
y.<br>
<br>
A low-hanging fruit is that if anything doesn&#39;t work with use strict it=
 is <br>
updated to declare its variables and so on.<br>
<br>
Personally I do NOT advocate that signatures or anything likely to change b=
e <br>
turned on by default, but simpler things unlikely to change should be like =
&quot;say&quot;.<br></blockquote><div><br></div><div>I am just going to say=
, I think you have not been paying attention to many of the attempts to do =
things just like this on CPAN previously if you think this is attainable,=
=C2=A0nevermind easy. We are still trying to get rid of problematic uses of=
 Module::Install to this day.</div><div><br></div><div>-Dan=C2=A0</div></di=
v></div>

--000000000000d1d3d405a94772d0--
0
grinnz
6/30/2020 6:39:50 AM
--000000000000aaac1905a9477941
Content-Type: text/plain; charset="UTF-8"

On Tue, Jun 30, 2020 at 2:38 AM Todd Rinaldo <toddr@cpanel.net> wrote:

>
>
> On Jun 28, 2020, at 8:00 PM, Dan Book <grinnz@gmail.com> wrote:
>
> To start with, having installers inject code into CPAN modules is both a
> licensing and technical issue. The artistic license does not permit
> modifying the code without changing the name. Injecting code changes line
> numbers from what you find on CPAN. Can these be solved? Perhaps, but not
> without discussing these things.
>
>
> Are you suggesting that changing the #! at the top of installed perl files
> (which we already do) is a license violation?
>

I don't think it is because it's a necessary part of the install process
for scripts and it's a comment, but my point was this is among the
discussions that hasn't even happened yet.

-Dan

--000000000000aaac1905a9477941
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Tue, Jun 30, 2020 at 2:38 AM Todd Rina=
ldo &lt;<a href=3D"mailto:toddr@cpanel.net">toddr@cpanel.net</a>&gt; wrote:=
<br></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex"><div style=3D"overflow-wrap: break-word;"><br><div><br><blockqu=
ote type=3D"cite"><div>On Jun 28, 2020, at 8:00 PM, Dan Book &lt;<a href=3D=
"mailto:grinnz@gmail.com" target=3D"_blank">grinnz@gmail.com</a>&gt; wrote:=
</div><br><div><span style=3D"font-family:Helvetica;font-size:12px;font-sty=
le:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal=
;text-align:start;text-indent:0px;text-transform:none;white-space:normal;wo=
rd-spacing:0px;text-decoration:none;float:none;display:inline">To start wit=
h, having installers inject code into CPAN modules is both a licensing and =
technical issue. The artistic license does not permit modifying the code wi=
thout changing the name. Injecting code changes line numbers from what you =
find on CPAN. Can these be solved? Perhaps, but not without discussing thes=
e things.</span></div></blockquote></div><br><div>Are you suggesting that c=
hanging the #! at the top of installed perl files (which we already do) is =
a license violation?</div></div></blockquote><div><br></div><div>I don&#39;=
t think it is because it&#39;s a necessary=C2=A0part of the install process=
 for scripts and it&#39;s a comment, but my point was this is among the dis=
cussions that hasn&#39;t even happened yet.</div><div><br></div><div>-Dan=
=C2=A0</div></div></div>

--000000000000aaac1905a9477941--
0
grinnz
6/30/2020 6:41:45 AM

> On Jun 29, 2020, at 3:56 AM, Paul LeoNerd Evans =
<leonerd@leonerd.org.uk> wrote:
>=20
> On Sun, 28 Jun 2020 03:39:52 -0500
> Todd Rinaldo <toddr@cpanel.net> wrote:
>=20
>> Easily. They check $].
>=20
> Todd, please explain how github's syntax highlighter checks the value
> of $] when highlighting a .pm file.
>=20
> Or for that matter even metacpan.org. How will our own infrastructure
> know what version of perl syntax rules to be using when highlighting
> our own code?
>=20

It doesn't. That is a good point.
0
toddr
6/30/2020 6:56:30 AM
On 30/6/20 1:09, Eric Brine wrote:
 > On Sat, Jun 27, 2020 at 12:46 PM Dan Book <grinnz@gmail.com
 > <mailto:grinnz@gmail.com>> wrote:
 >
 >     unicode_strings causes a specific set of functions in that lexical
 >     scope to use Unicode rules when determining how they interact with a
 >     string, instead of possibly using ASCII rules if the string is
 >     downgraded as the previous heuristic did.
 >
 >
 > Or put otherwise, it simply fixes a handful of builtin functions that
 > otherwise suffer from The Unicode Bug (behave differently depending on
 > the internal storage format of the their input).

In the case of functions that interface with the external world it is 
not as easy as saying they should expect the data to be in the native 
Unicode encoding (i.e. UTF-8 or UTF-16), specially if that is going to 
be the default behavior in p7.

Nowadays, on Windows, Linux and probably most UNIX variants UTF8 (or 
UTF16) is usually the default encoding for the file system metadata, but 
the OS does nothing to enforce that. Filenames can still contain byte 
(or wchar_t) sequences that are not valid.

In my experience, those broken names are not so rare, due to buggy 
software, old data from times when latin1 was still the norm, file 
systems with a fixed encoding, etc.

IMO, it would be a mistake to have perl throw an error when encountering 
any such data. On the contrary, it should be able to read, process and 
write it back untouched, end to end.

For instance:

    my $fn = readdir $dh;
    open my $fh, ">/tmp/$fn"

Should be able to read a filename with a broken name and create a new 
one with exactly the same broken name.

Doing otherwise would leave to the programmer the burden of explicitly 
handling those cases.

And BTW, Raku already does that using the UTF8-C8 encoding: 
https://docs.raku.org/language/unicode
0
sfandino
6/30/2020 9:48:16 AM
On Tue, 30 Jun 2020 11:48:16 +0200
Salvador Fandiño <sfandino@gmail.com> wrote:

> In the case of functions that interface with the external world it is not as easy as saying they should expect the data to be in the native Unicode encoding (i.e. UTF-8 or UTF-16), specially if that is going to be the default behavior in p7.

That is not what 'unicode_strings' does. It doesn't prevent you from
working on bytes.

Read this for more info: https://perldoc.pl/perlunicode#The-%22Unicode-Bug%22
0
me
6/30/2020 10:00:28 AM
On 30/6/20 6:40, Darren Duncan wrote:
> Having taken more time to think about this, and seeing more discussion, 
> I have come around further towards supporting a key aspect of Sawyer's 
> proposal.
> 
> 1. I no longer believe that a v7+ Perl interpreter should consider it 
> mandatory for each Perl file to start with a "use <version>;" and 
> instead I take the position that using such declarations should just be 
> strongly encouraged, particularly for any Perl code meant to be shared 
> with others.

But the thing is, some newbie writes a script in the all new perl 7 and 
doesn't start it with the "use v7;" line. It works, everything is fine.

A couple of years into the future, a new release of Perl with some 
incompatible changes is ready, perl 8. You follow the same logic: "use 
v8;" is not mandatory, new features are enabled by default and so, a 
good bunch of perl 7 scripts and modules become broken, and people is 
forced to change then adding a "use compact::perl7" line?

It doesn't makes sense to me.

It you want to avoid the "use v7;" line, then you should be able to tell 
perl explicitly in some way you want the 7 semantics. The only sane way 
I can see for that, is using different file terminations. I.e. p7, pl7, 
pm7, t7.

And when perl 8 comes out, you can switch to p8, pl8, etc.
0
sfandino
6/30/2020 10:02:10 AM
On Tue, 30 Jun 2020 12:02:10 +0200
Salvador Fandi=C3=B1o <sfandino@gmail.com> wrote:

> It you want to avoid the "use v7;" line, then you should be able to
> tell perl explicitly in some way you want the 7 semantics. The only
> sane way I can see for that, is using different file terminations.
> I.e. p7, pl7, pm7, t7.
>=20
> And when perl 8 comes out, you can switch to p8, pl8, etc.

This would be an odd suggestion.

I believe the main motivation for people saying they don't want to
"use v7" is precisely to avoid having to update to "use v8" and so on
in the future; having to chase the latest-and-greatest by making a
single character change to their code every decade or so.

If they don't want to do that, I really don't think they will want to
rename their files either. In practice it amounts to the same thing.

--=20
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk      |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/
0
leonerd
6/30/2020 11:37:48 AM
On Mon, 29 Jun 2020 20:54:50 -0700
Darren Duncan <darren@darrenduncan.net> wrote:

> - An integer, meaning an IV.
> - A floating-point number, meaning an FV.
NV

> - A string of octets, meaning one kind of SV.
> - A string of characters, meaning a different kind of SV.
These are both PVs.

But nope. Core perl does not in any way distinguish a string of octets
from a string of characters, any more than it distinguishes a string of
English from a string of German, or SQL, or HTML.

-- 
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk      |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/
0
leonerd
6/30/2020 11:40:14 AM
On Tue, 30 Jun 2020 01:56:30 -0500
Todd Rinaldo <toddr@cpanel.net> wrote:

> > On Jun 29, 2020, at 3:56 AM, Paul LeoNerd Evans
> > <leonerd@leonerd.org.uk> wrote:
> > 
> > Todd, please explain how github's syntax highlighter checks the
> > value of $] when highlighting a .pm file.
> > 
> > Or for that matter even metacpan.org. How will our own
> > infrastructure know what version of perl syntax rules to be using
> > when highlighting our own code?
> >   
> 
> It doesn't. That is a good point.

Thank you.

So, we can accept that "use v7" would be one possible mechanism by which
metacpan, github, perltidy, etc. can all use to determine what syntax
rules and hence what highlighting and formatting to apply. But likely
there may be others.

Can we think of any others? If you want to strongly make the case that
"use v7" will not be required, you will have to find a different
mechanism by which all of the above can continue to do the right thing.

-- 
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk      |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/
0
leonerd
6/30/2020 11:42:46 AM
On 30/6/20 13:37, Paul "LeoNerd" Evans wrote:
> On Tue, 30 Jun 2020 12:02:10 +0200
> Salvador Fandiño <sfandino@gmail.com> wrote:
> 
>> It you want to avoid the "use v7;" line, then you should be able to
>> tell perl explicitly in some way you want the 7 semantics. The only
>> sane way I can see for that, is using different file terminations.
>> I.e. p7, pl7, pm7, t7.
>>
>> And when perl 8 comes out, you can switch to p8, pl8, etc.
> 
> This would be an odd suggestion.
> 
> I believe the main motivation for people saying they don't want to
> "use v7" is precisely to avoid having to update to "use v8" and so on
> in the future; having to chase the latest-and-greatest by making a
> single character change to their code every decade or so.

But that just completely misses the point that some of your fine perl 7 
code would break when run under the perl 8 interpreter unless you hint 
it to use the perl 7 semantics, in some way, right?

I don't know if other people like to revisit their old code frequently 
and update it to use new features as they become available. Definitively 
that's not my case!
0
sfandino
6/30/2020 11:53:25 AM
On Tue, 30 Jun 2020 13:53:25 +0200
Salvador Fandi=C3=B1o <sfandino@gmail.com> wrote:

> > I believe the main motivation for people saying they don't want to
> > "use v7" is precisely to avoid having to update to "use v8" and so
> > on in the future; having to chase the latest-and-greatest by making
> > a single character change to their code every decade or so. =20
>=20
> But that just completely misses the point that some of your fine perl
> 7 code would break when run under the perl 8 interpreter unless you
> hint it to use the perl 7 semantics, in some way, right?

Which is exactly the state that we are currently in where we have a
great amount of existing perl 5 code (CPAN, DarkPAN, personal repoes,
etc..) which would break when run under the perl 7 in interpreter, for
exactly the same category of reasons.

> I don't know if other people like to revisit their old code
> frequently and update it to use new features as they become
> available. Definitively that's not my case!

Oh indeed. I personally am greatly in favour of continuing to declare
what version of perl semantics the author wishes to have. I think just
dragging people along to the latest-and-greatest without their
opting-in is a terrible idea.

The point of my message was simply to say that the people objecting to
"use v7" are objecting to the "I have to declare that 7 in some way"
part of it - and I suspect (though I may be putting words in their
mouths here) that they would be equally opposed to declaring the 7 by
way of the filename extension, as they would be in a "use" statement.

--=20
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk      |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/
0
leonerd
6/30/2020 12:06:24 PM
On Tue, 30 Jun 2020 08:32:43 +0200, Todd Rinaldo <toddr@cpanel.net> wrote:

>
>
>> On Jun 28, 2020, at 7:33 AM, Andreas Koenig <andreas.koenig.7os6VVqR@franz.ak.mind.de> wrote:
>>
>>>>>>> On Sun, 28 Jun 2020 03:39:52 -0500, Todd Rinaldo <toddr@cpanel.net> said:
>>
>>>> On Jun 28, 2020, at 2:38 AM, Paul LeoNerd Evans <leonerd@leonerd.org.uk> wrote:
>>>>
>>>> If `try` syntax becomes default - probably not in 7 but maybe in 8 -
>>>> then how is perltidy going to know how to properly format and indent
>>>> this, and all the other exciting syntax we hope to have in place by 8?
>>>>
>>
>>> Easily. They check $].
>>
>> Hi Todd,
>>
>> this does not work. For example, see here is a line of perl code:
>>
>>  print "Hello, Rinaldo";
>>
>> So what is $] in this line and how do you find out? If you simply run
>> it, you make a decision, with which interpreter you start it. And hereby
>> you influence the outcome for $]. So: the value of $] is a result of
>> your decision, not something intrinsic to the code.
>>
>> --
>> andreas
>
> My suggestion was that the version of perl critic runs under should dictate how it behaves.

Tryna be polite:

No.

Love,
the maintainer of the engine within Perl::Critic
0
walde
6/30/2020 12:42:18 PM
--00000000000041182d05a94c839e
Content-Type: text/plain; charset="UTF-8"

Based on both Kent's email and Leon's blog post
<http://blogs.perl.org/users/leon_timmermans/2020/06/not-quite-getting-better-yet.html>,
I now agree with Dave Mitchell: Perl 7 should be fully backwards
compatible. Lots of Linuxes as well as Mac include Perl in their base
install. I believe we can solve a CPAN Perl 7 incompatibility with tooling,
but not the Linux infrastructure. Full backwards compatibility means an
upgrade to Perl 7 would be mostly (entirely?) painless for most vendors (no
harder than a current point upgrade is at the moment), so new users of
those OSes would get the latest Perl "for free."

I still think we should optimize for the new user. Requiring "use v7" is a
small price to pay if it means that Perl 7 is automatically installed on
their computer.

David

--00000000000041182d05a94c839e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"auto"><div><div class=3D"gmail_quote"><div cla=
ss=3D"gmail_quote">Based on both Kent&#39;s email and <a href=3D"http://blo=
gs.perl.org/users/leon_timmermans/2020/06/not-quite-getting-better-yet.html=
">Leon&#39;s blog post</a>, I now agree with Dave Mitchell: Perl 7 should b=
e fully backwards compatible. Lots of Linuxes as well as Mac include Perl i=
n their base install. I believe we can solve a CPAN Perl 7 incompatibility =
with tooling, but not the Linux infrastructure. Full backwards compatibilit=
y means an upgrade to Perl 7 would be mostly (entirely?) painless for most =
vendors (no harder than a current point upgrade is at the moment), so new u=
sers of those OSes would get the latest Perl &quot;for free.&quot;<br><div>=
<br></div><div>I still think we should optimize for the new user. Requiring=
 &quot;use v7&quot; is a small price to pay if it means that Perl 7 is auto=
matically installed on their computer.</div><div><br></div><div>David<br></=
div></div></div></div><div dir=3D"auto"></div></div>
</div>

--00000000000041182d05a94c839e--
0
dcmertens
6/30/2020 12:42:33 PM
On 06/30/2020 02:00, Darren Duncan wrote:
> On 2020-06-29 10:40 p.m., Tom Molesworth wrote:
>> On Tue, 30 Jun 2020 at 13:33, Darren Duncan wrote:
>>
>> =C2=A0=C2=A0=C2=A0 On 2020-06-29 10:22 p.m., Tom Molesworth via perl5-=
porters wrote:
>> =C2=A0=C2=A0=C2=A0=C2=A0 > So one concern that does not seem to have b=
een addressed by=20
>> the "enable by
>> =C2=A0=C2=A0=C2=A0=C2=A0 > default" proposal is "what about CPAN". It =
used to be a=20
>> selling point for
>> =C2=A0=C2=A0=C2=A0 Perl,
>> =C2=A0=C2=A0=C2=A0=C2=A0 > would be a shame to lose that.
>>
>> =C2=A0=C2=A0=C2=A0 Well I DID say that CPAN is one of those places whe=
re explicit=20
>> versions SHOULD
>> =C2=A0=C2=A0=C2=A0 be used.=C2=A0 And if any don't, well CPAN is publi=
c, and as you=20
>> demonstrated we can
>> =C2=A0=C2=A0=C2=A0 see what would break.=C2=A0 And so we now are in th=
e position to fix=20
>> those modules.
>>
>> Fix... how?
> Fix means make compatible.=C2=A0 And the argument is for the community =
at=20
> large to do it, not just those who maintain the Perl interpreter.

Not quite.=C2=A0 "Fix" means "make compatible with perl7".=C2=A0 As has b=
een=20
discussed and quantified earlier, a significant subset of CPAN can't be=20
compatible with both languages simultaneously.=C2=A0 In that context, "fi=
x"=20
is in effect a top-down mandate for users to abandon perl5.

"Fix" also deprecates 5PAN as broken, the belief of which makes the=20
mandate more palatable.

--=20
End of message.
0
rcaputo
6/30/2020 2:31:48 PM
--000000000000659cef05a94e1018
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 30, 2020 at 1:41 PM Paul "LeoNerd" Evans <leonerd@leonerd.org.u=
k>
wrote:

> On Mon, 29 Jun 2020 20:54:50 -0700
> Darren Duncan <darren@darrenduncan.net> wrote:
> > - A string of octets, meaning one kind of SV.
> > - A string of characters, meaning a different kind of SV.
> These are both PVs.
>
> But nope. Core perl does not in any way distinguish a string of octets
> from a string of characters, any more than it distinguishes a string of
> English from a string of German, or SQL, or HTML.
>

  =E2=80=A6 except when it does.

  Like when core perl is dealing with the file system.

  Seriously, can't someone just declare all such instances bugs (however
long-standing), and fix them one way or another?


Eirik

--000000000000659cef05a94e1018
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tue, Jun 30, 2020 at 1:41 PM Paul &quot;LeoNerd&quot; E=
vans &lt;<a href=3D"mailto:leonerd@leonerd.org.uk">leonerd@leonerd.org.uk</=
a>&gt; wrote:<br><div><div class=3D"gmail_quote"><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204=
,204);padding-left:1ex">On Mon, 29 Jun 2020 20:54:50 -0700<br>
Darren Duncan &lt;<a href=3D"mailto:darren@darrenduncan.net" target=3D"_bla=
nk">darren@darrenduncan.net</a>&gt; wrote:<br>
&gt; - A string of octets, meaning one kind of SV.<br>
&gt; - A string of characters, meaning a different kind of SV.<br>
These are both PVs.<br>
<br>
But nope. Core perl does not in any way distinguish a string of octets<br>
from a string of characters, any more than it distinguishes a string of<br>
English from a string of German, or SQL, or HTML.<br></blockquote><div><br>=
</div>=C2=A0 =E2=80=A6 except when it does.</div><div class=3D"gmail_quote"=
><br></div><div class=3D"gmail_quote">=C2=A0 Like when core perl is dealing=
 with the file system.</div><div class=3D"gmail_quote"><br></div><div class=
=3D"gmail_quote">=C2=A0 Seriously, can&#39;t someone just declare all such =
instances bugs=20
(however long-standing), and fix them one way or another?<br></div><div cla=
ss=3D"gmail_quote"><br></div><div class=3D"gmail_quote"><br></div><div clas=
s=3D"gmail_quote">Eirik<br></div></div></div>

--000000000000659cef05a94e1018--
0
Eirik
6/30/2020 2:33:39 PM
On Tue, Jun 30, 2020 at 5:55 AM Darren Duncan <darren@darrenduncan.net> wrote:
> - An integer, meaning an IV.
> - A floating-point number, meaning an FV.
> - A string of octets, meaning one kind of SV.
> - A string of characters, meaning a different kind of SV.
>
> I for one would love to have a very easy way to introspect, in a very strict
> manner, exactly which one of these 4 we have.

What we would need is types based on intention; "is it text or a
binary". Internal encoding is entirely irrelevant for that.

Problem is, in all old Perl code this distinction is not being made,
so the value you'd get is unreliable. Effectively this is very much a
"this breaks all of CPAN" kind of change.

I get why you want this 100%, but I'm not seeing any solution for it :-/.






> Ideally there would be a disjoint representation of a pure boolean as well, that
> is distinct from 0 or 1 or "" or so on, like any other good modern language has.



> A key business requirement I have is that I can write code that takes a generic
> Perl scalar as input and do different things depending on which type it is in
> the strict sense, because it can distinguish them without any extra metadata not
> in the scalar itself.  I can workaround gaps in this by supplying metadata
> externally, but that is a more verbose and slower user experience than it being
> natively part of Perl scalars.
0
fawaka
6/30/2020 3:38:57 PM
On Tue, 30 Jun 2020 at 11:51, Dan Book <grinnz@gmail.com> wrote:

>  but a feature that allows one to declare explicit intentions as magic attached to strings would be the beginnings of a very useful system to help people who don't understand the setup or how one should approach character encoding,


Not exactly a new idea, just all the other times this was proposed, it
turned out to be prohibitive to actually do.

https://www.nntp.perl.org/group/perl.perl5.porters/2015/01/msg224867.html
https://www.nntp.perl.org/group/perl.perl5.porters/2015/06/msg228670.html


-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL
0
kentfredric
6/30/2020 6:51:33 PM
On 2020-06-30 3:02 a.m., Salvador Fandiño wrote:
> On 30/6/20 6:40, Darren Duncan wrote:
>> Having taken more time to think about this, and seeing more discussion, I have 
>> come around further towards supporting a key aspect of Sawyer's proposal.
>>
>> 1. I no longer believe that a v7+ Perl interpreter should consider it 
>> mandatory for each Perl file to start with a "use <version>;" and instead I 
>> take the position that using such declarations should just be strongly 
>> encouraged, particularly for any Perl code meant to be shared with others.
> 
> But the thing is, some newbie writes a script in the all new perl 7 and doesn't 
> start it with the "use v7;" line. It works, everything is fine.
> 
> A couple of years into the future, a new release of Perl with some incompatible 
> changes is ready, perl 8. You follow the same logic: "use v8;" is not mandatory, 
> new features are enabled by default and so, a good bunch of perl 7 scripts and 
> modules become broken, and people is forced to change then adding a "use 
> compact::perl7" line?

I strongly disagree with "compat::perl7"; what they should be doing then is 
adding "use v7;" which is the exact same thing they could have added before but 
didn't, and that would still work on Perl 7.

> It doesn't makes sense to me.
> 
> It you want to avoid the "use v7;" line, then you should be able to tell perl 
> explicitly in some way you want the 7 semantics. The only sane way I can see for 
> that, is using different file terminations. I.e. p7, pl7, pm7, t7.
> 
> And when perl 8 comes out, you can switch to p8, pl8, etc.

I typically consider that adding new version-specific filename extensions is a 
horrible idea.  I hated the .pl6/.p6 extensions (.raku was so much better) and I 
hate the idea of pl7 etc.  Stick to .pl/.pm and recognize versions by the 
contents of the files.

-- Darren Duncan
0
darren
6/30/2020 11:16:47 PM
On 2020-06-30 7:31 a.m., Rocco Caputo wrote:
> On 06/30/2020 02:00, Darren Duncan wrote:
>> On 2020-06-29 10:40 p.m., Tom Molesworth wrote:
>>> On Tue, 30 Jun 2020 at 13:33, Darren Duncan wrote:
>>>
>>>     On 2020-06-29 10:22 p.m., Tom Molesworth via perl5-porters wrote:
>>>      > 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.
>>>
>>>     Well I DID say that CPAN is one of those places where explicit versions 
>>> SHOULD
>>>     be used.  And if any don't, well CPAN is public, and as you demonstrated 
>>> we can
>>>     see what would break.  And so we now are in the position to fix those 
>>> modules.
>>>
>>> Fix... how?
>> Fix means make compatible.  And the argument is for the community at large to 
>> do it, not just those who maintain the Perl interpreter.
> 
> Not quite.  "Fix" means "make compatible with perl7".  As has been discussed and 
> quantified earlier, a significant subset of CPAN can't be compatible with both 
> languages simultaneously.  In that context, "fix" is in effect a top-down 
> mandate for users to abandon perl5.
> 
> "Fix" also deprecates 5PAN as broken, the belief of which makes the mandate more 
> palatable.

I am operating under the assumption here that it is possible and sufficiently 
easy to write Perl code that is compatible with both Perl 5 and Perl 7+ at the 
same time.  The vast majority of syntax should be in the common subset of both 
versions, and when one writes to that both should just work.  So "fix" means 
ensure just the common subset is used.  I want a single CPAN to work for both 
versions. -- Darren Duncan
0
darren
6/30/2020 11:23:52 PM
On 2020-06-30 5:42 a.m., David Mertens wrote:
> Based on both Kent's email and Leon's blog post 
> <http://blogs.perl.org/users/leon_timmermans/2020/06/not-quite-getting-better-yet.html>, 
> I now agree with Dave Mitchell: Perl 7 should be fully backwards compatible. 
> Lots of Linuxes as well as Mac include Perl in their base install. I believe we 
> can solve a CPAN Perl 7 incompatibility with tooling, but not the Linux 
> infrastructure. Full backwards compatibility means an upgrade to Perl 7 would be 
> mostly (entirely?) painless for most vendors (no harder than a current point 
> upgrade is at the moment), so new users of those OSes would get the latest Perl 
> "for free."
> 
> I still think we should optimize for the new user. Requiring "use v7" is a small 
> price to pay if it means that Perl 7 is automatically installed on their computer.

I wouldn't use MacOS as an example of this.  Apple has already deprecated 
including any scripting languages in their base install as of last year's 
Catalina release.  Until they actually remove them I find it highly unlikely 
they will do anything other than just be frozen at the Perl version they 
currently include which is 5.18.4 or 6 major versions back. -- Darren Duncan
0
darren
6/30/2020 11:26:49 PM
On 06/30/2020 19:23, Darren Duncan wrote:
> On 2020-06-30 7:31 a.m., Rocco Caputo wrote:
>> On 06/30/2020 02:00, Darren Duncan wrote:
>>> On 2020-06-29 10:40 p.m., Tom Molesworth wrote:
>>>> On Tue, 30 Jun 2020 at 13:33, Darren Duncan wrote:
>>>>
>>>> =C2=A0=C2=A0=C2=A0 On 2020-06-29 10:22 p.m., Tom Molesworth via perl=
5-porters wrote:
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 > So one concern that does not seem to have=
 been addressed by=20
>>>> the "enable by
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 > default" proposal is "what about CPAN". I=
t used to be a=20
>>>> selling point for
>>>> =C2=A0=C2=A0=C2=A0 Perl,
>>>> =C2=A0=C2=A0=C2=A0=C2=A0 > would be a shame to lose that.
>>>>
>>>> =C2=A0=C2=A0=C2=A0 Well I DID say that CPAN is one of those places w=
here explicit=20
>>>> versions SHOULD
>>>> =C2=A0=C2=A0=C2=A0 be used.=C2=A0 And if any don't, well CPAN is pub=
lic, and as you=20
>>>> demonstrated we can
>>>> =C2=A0=C2=A0=C2=A0 see what would break.=C2=A0 And so we now are in =
the position to fix=20
>>>> those modules.
>>>>
>>>> Fix... how?
>>> Fix means make compatible.=C2=A0 And the argument is for the communit=
y at=20
>>> large to do it, not just those who maintain the Perl interpreter.
>>
>> Not quite.=C2=A0 "Fix" means "make compatible with perl7".=C2=A0 As ha=
s been=20
>> discussed and quantified earlier, a significant subset of CPAN can't=20
>> be compatible with both languages simultaneously.=C2=A0 In that contex=
t,=20
>> "fix" is in effect a top-down mandate for users to abandon perl5.
>>
>> "Fix" also deprecates 5PAN as broken, the belief of which makes the=20
>> mandate more palatable.
>
> I am operating under the assumption here that it is possible and=20
> sufficiently easy to write Perl code that is compatible with both Perl=20
> 5 and Perl 7+ at the same time.=C2=A0 The vast majority of syntax shoul=
d be=20
> in the common subset of both versions, and when one writes to that=20
> both should just work.=C2=A0 So "fix" means ensure just the common subs=
et=20
> is used.=C2=A0 I want a single CPAN to work for both versions. -- Darre=
n Duncan

Given that perl7 is to be unshackled from perl5 compatibility, it's not=20
unreasonable to expect that the "common subset" that fixed CPAN modules=20
may use will shrink over time.=C2=A0 Modules wishing to use both language=
s=20
will occasionally break and be required to re-evaluate whether to=20
continue being compatible with one language or the other.=C2=A0 Those tha=
t=20
continue to choose both may need to pare down their use of language=20
features to remain within the shrinking common subset.

"Fix" is also fine word for this situation, as it can imply "neuter".

--=20
End of message.
0
rcaputo
7/1/2020 12:06:05 AM
On 2020-06-30 5:06 p.m., Rocco Caputo wrote:
> On 06/30/2020 19:23, Darren Duncan wrote:
>> I am operating under the assumption here that it is possible and sufficiently 
>> easy to write Perl code that is compatible with both Perl 5 and Perl 7+ at the 
>> same time.  The vast majority of syntax should be in the common subset of both 
>> versions, and when one writes to that both should just work.  So "fix" means 
>> ensure just the common subset is used.  I want a single CPAN to work for both 
>> versions. -- Darren Duncan
> 
> Given that perl7 is to be unshackled from perl5 compatibility, it's not 
> unreasonable to expect that the "common subset" that fixed CPAN modules may use 
> will shrink over time.  Modules wishing to use both languages will occasionally 
> break and be required to re-evaluate whether to continue being compatible with 
> one language or the other.  Those that continue to choose both may need to pare 
> down their use of language features to remain within the shrinking common subset.

Yes, it is as you say, but that's not a problem.

For the next year at least, the common subset is mostly just what you get when 
you have followed what is best practices anyway for Perl 5 code.  Those who 
already do this are most of the way there, and otherwise getting them there best 
is doing this.  So to get the Perl 5 and Perl 7 overlap is mostly just following 
best practices.

That means Perl code that satisfies use-strict and use-warnings and doesn't use 
indirect notation and doesn't use bareword filehandles and so on.

Certain experimental things like routine signatures or smart match would be 
avoided for the maximal coverage, say if you want to work with everything from 
5.008 thru 7+, which is what I would be doing with my CPAN projects for awhile.

If one wants to use routine signatures, then their best bet is probably to "use 
Perl 5.28" or whatever introduced the current version of that and had the last 
breaking change.  Then one has the greatest Perl language feature set to use 
that is still nominally both Perl 5 and Perl 7+.

In general, best practice for CPAN modules is to explicitly have "use N;" to 
indicate the lower bound of the total set of Perl versions that provides the 
language features they want to use, and over time they gradually increase that 
lower bound as they want to use more features.

But the point is, subject to each developer making their own choice on what they 
want to support, it is very doable for an extended period to use a langauage 
subset that at least overlaps with SOME versions of Perl 5.

The real trouble will come when/if Perl evolves so much that the common subset 
of that and Perl 5.32.0 is uselessly small, but even with a lot of freedom to 
evolve I doubt that will happen for quite awhile.

-- Darren Duncan
0
darren
7/1/2020 3:13:05 AM
On Tue, 30 Jun 2020 20:13:05 -0700
Darren Duncan <darren@darrenduncan.net> wrote:

> In general, best practice for CPAN modules is to explicitly have "use
> N;" to indicate the lower bound of the total set of Perl versions
> that provides the language features they want to use, and over time
> they gradually increase that lower bound as they want to use more
> features.

Indeed.

And it is exactly this behaviour that is being argued *against*.

The announced idea with "perl 7" was that you wouldn't have to "use N"
to get those features. They'd just be foist upon you whether you like
it or not.

It is this behaviour to which we are all objecting.

I would love for a Perl 7 to exist, with all these nice new features -
including several I'm still midway through writing (try/catch,
dumbmatch, true exception types, ... objects?). I just want to ensure
this is done smoothly, via "use N", and not just dropped in on everyone
who wasn't expecting it.

-- 
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk      |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/
0
leonerd
7/1/2020 10:06:21 AM
On Tue, 30 Jun 2020 16:16:47 -0700
Darren Duncan <darren@darrenduncan.net> wrote:

> I strongly disagree with "compat::perl7"; what they should be doing
> then is adding "use v7;" which is the exact same thing they could
> have added before but didn't, and that would still work on Perl 7.

+1 to that.

> > It doesn't makes sense to me.
> > 
> > It you want to avoid the "use v7;" line, then you should be able to
> > tell perl explicitly in some way you want the 7 semantics. The only
> > sane way I can see for that, is using different file terminations.
> > I.e. p7, pl7, pm7, t7.
> > 
> > And when perl 8 comes out, you can switch to p8, pl8, etc.  
> 
> I typically consider that adding new version-specific filename
> extensions is a horrible idea.  I hated the .pl6/.p6 extensions
> (.raku was so much better) and I hate the idea of pl7 etc.  Stick to
> .pl/.pm and recognize versions by the contents of the files.

+1 also.

I believe we are in complete agreement here :)

-- 
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk      |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/
0
leonerd
7/1/2020 10:07:41 AM
On 1/7/20 1:16, Darren Duncan wrote:
> On 2020-06-30 3:02 a.m., Salvador Fandiño wrote:
>> On 30/6/20 6:40, Darren Duncan wrote:
>>> Having taken more time to think about this, and seeing more 
>>> discussion, I have come around further towards supporting a key 
>>> aspect of Sawyer's proposal.
>>>
>>> 1. I no longer believe that a v7+ Perl interpreter should consider it 
>>> mandatory for each Perl file to start with a "use <version>;" and 
>>> instead I take the position that using such declarations should just 
>>> be strongly encouraged, particularly for any Perl code meant to be 
>>> shared with others.
>>
>> But the thing is, some newbie writes a script in the all new perl 7 
>> and doesn't start it with the "use v7;" line. It works, everything is 
>> fine.
>>
>> A couple of years into the future, a new release of Perl with some 
>> incompatible changes is ready, perl 8. You follow the same logic: "use 
>> v8;" is not mandatory, new features are enabled by default and so, a 
>> good bunch of perl 7 scripts and modules become broken, and people is 
>> forced to change then adding a "use compact::perl7" line?
> 
> I strongly disagree with "compat::perl7"; what they should be doing then 
> is adding "use v7;" which is the exact same thing they could have added 
> before but didn't, and that would still work on Perl 7.

Well, that compat::perl7 thing was mostly a joke, not a serious 
suggestion!!!

What I was trying to emphasize is that unless you explicitly declare the 
perl version semantics you want to use in some way (and I am 
definitively in the "use v7" camp here), your code would become broken 
in the next mayor release, if that follows an 
all-features-enabled-by-default policy.

In the end what I am trying to show here is that an 
all-features-enabled-by-default policy is broken unless you admit it 
would be ok to force everybody to revise *all its code* every time a new 
mayor version comes out, just to ensure that it remains compatible with 
the new features added to the language.

So, it doesn't make sense for perl7 and it will not make sense for 
perl8, etc.

> 
>> It doesn't makes sense to me.
>>
>> It you want to avoid the "use v7;" line, then you should be able to 
>> tell perl explicitly in some way you want the 7 semantics. The only 
>> sane way I can see for that, is using different file terminations. 
>> I.e. p7, pl7, pm7, t7.
>>
>> And when perl 8 comes out, you can switch to p8, pl8, etc.
> 
> I typically consider that adding new version-specific filename 
> extensions is a horrible idea.  I hated the .pl6/.p6 extensions (.raku 
> was so much better) and I hate the idea of pl7 etc.  Stick to .pl/.pm 
> and recognize versions by the contents of the files.

Just to be clear, I don't particularly like that either. I think the 
best way to enable p7 semantics is to require the "use v7" line.

That was just an alternative in case the "use v7" option is completely 
ruled out.

Also, note that both solutions are not incompatible.
0
sfandino
7/1/2020 11:18:52 AM
On Wed, 1 Jul 2020 at 23:19, Salvador Fandi=C3=B1o <sfandino@gmail.com> wro=
te:
> What I was trying to emphasize is that unless you explicitly declare the
> perl version semantics you want to use in some way (and I am
> definitively in the "use v7" camp here), your code would become broken
> in the next mayor release, if that follows an
> all-features-enabled-by-default policy.

If this heads this way, I hope they have a provision in place for
"your code conflicts with a feature that will be enabled in perl ( $]
+ 0.2 )" warnings like has been expected of the majority previous
backwards compatibility breaks.

But that's ... probably going to be a *mountain* of fun to actually impleme=
nt.


--=20
Kent

KENTNL - https://metacpan.org/author/KENTNL
0
kentfredric
7/1/2020 11:56:16 AM

> On Jul 1, 2020, at 6:56 AM, Kent Fredric <kentfredric@gmail.com> =
wrote:
>=20
> On Wed, 1 Jul 2020 at 23:19, Salvador Fandi=C3=B1o =
<sfandino@gmail.com> wrote:
>> What I was trying to emphasize is that unless you explicitly declare =
the
>> perl version semantics you want to use in some way (and I am
>> definitively in the "use v7" camp here), your code would become =
broken
>> in the next mayor release, if that follows an
>> all-features-enabled-by-default policy.
>=20
> If this heads this way, I hope they have a provision in place for
> "your code conflicts with a feature that will be enabled in perl ( $]
> + 0.2 )" warnings like has been expected of the majority previous
> backwards compatibility breaks.
>=20
> But that's ... probably going to be a *mountain* of fun to actually =
implement.
>=20

I think some tooling that ships with Perl and gives this advice or =
upgrades it would be very helpful. Potentially something that =
auto-upgraded would be nice.=20

Example: Something that fixes indirect object notation automagically.

Todd
0
toddr
7/1/2020 12:37:35 PM
--00000000000064d79b05a961e18a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Jul 1, 2020 at 8:37 AM Todd Rinaldo <toddr@cpanel.net> wrote:

>
>
> > On Jul 1, 2020, at 6:56 AM, Kent Fredric <kentfredric@gmail.com> wrote:
> >
> > On Wed, 1 Jul 2020 at 23:19, Salvador Fandi=C3=B1o <sfandino@gmail.com>
> wrote:
> >> What I was trying to emphasize is that unless you explicitly declare t=
he
> >> perl version semantics you want to use in some way (and I am
> >> definitively in the "use v7" camp here), your code would become broken
> >> in the next mayor release, if that follows an
> >> all-features-enabled-by-default policy.
> >
> > If this heads this way, I hope they have a provision in place for
> > "your code conflicts with a feature that will be enabled in perl ( $]
> > + 0.2 )" warnings like has been expected of the majority previous
> > backwards compatibility breaks.
> >
> > But that's ... probably going to be a *mountain* of fun to actually
> implement.
> >
>
> I think some tooling that ships with Perl and gives this advice or
> upgrades it would be very helpful. Potentially something that auto-upgrad=
ed
> would be nice.
>
> Example: Something that fixes indirect object notation automagically.
>

This is practically impossible. It's not even possible to statically detect
that indirect object notation is in use.

-Dan

--00000000000064d79b05a961e18a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Wed, Jul 1, 2020 at 8:37 AM Todd Rinal=
do &lt;<a href=3D"mailto:toddr@cpanel.net">toddr@cpanel.net</a>&gt; wrote:<=
br></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><br>
<br>
&gt; On Jul 1, 2020, at 6:56 AM, Kent Fredric &lt;<a href=3D"mailto:kentfre=
dric@gmail.com" target=3D"_blank">kentfredric@gmail.com</a>&gt; wrote:<br>
&gt; <br>
&gt; On Wed, 1 Jul 2020 at 23:19, Salvador Fandi=C3=B1o &lt;<a href=3D"mail=
to:sfandino@gmail.com" target=3D"_blank">sfandino@gmail.com</a>&gt; wrote:<=
br>
&gt;&gt; What I was trying to emphasize is that unless you explicitly decla=
re the<br>
&gt;&gt; perl version semantics you want to use in some way (and I am<br>
&gt;&gt; definitively in the &quot;use v7&quot; camp here), your code would=
 become broken<br>
&gt;&gt; in the next mayor release, if that follows an<br>
&gt;&gt; all-features-enabled-by-default policy.<br>
&gt; <br>
&gt; If this heads this way, I hope they have a provision in place for<br>
&gt; &quot;your code conflicts with a feature that will be enabled in perl =
( $]<br>
&gt; + 0.2 )&quot; warnings like has been expected of the majority previous=
<br>
&gt; backwards compatibility breaks.<br>
&gt; <br>
&gt; But that&#39;s ... probably going to be a *mountain* of fun to actuall=
y implement.<br>
&gt; <br>
<br>
I think some tooling that ships with Perl and gives this advice or upgrades=
 it would be very helpful. Potentially something that auto-upgraded would b=
e nice. <br>
<br>
Example: Something that fixes indirect object notation automagically.<br></=
blockquote><div><br></div><div>This is practically impossible. It&#39;s not=
 even possible to statically detect that indirect object notation is in use=
..</div><div><br></div><div>-Dan=C2=A0</div></div></div>

--00000000000064d79b05a961e18a--
0
grinnz
7/1/2020 2:11:55 PM
On Thu, 2 Jul 2020 at 00:37, Todd Rinaldo <toddr@cpanel.net> wrote:
> Example: Something that fixes indirect object notation automagically.
>
> Todd

I think you're forgetting prototypes are a thing, and you can't tell
if it's indirect or not, without consulting the prototype.

-------
#!perl
use strict;
use warnings;

{
  package Evil::Module;
  sub new {
    return "Hahaha";
  }
}
sub new(*;@) {
  sprintf "%s->(%s)\n", $_[0], join q[,], @_[1..$#_] ;
}

my $v = new Evil::Module,(qw(Hi Guys));

print $v;

--------------------

You take away the "sub new" with the "*" prototype declared on it, and
it reverts to being indirect.

Good luck parsing that.

-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL
0
kentfredric
7/1/2020 6:29:34 PM
--000000000000aed9a405a97774e8
Content-Type: text/plain; charset="UTF-8"

FYI, I have collected my core thoughts on the discussion here:
http://blogs.perl.org/users/grinnz/2020/07/perl-7-a-risk-benefit-analysis.html

-Dan

On Wed, Jun 24, 2020 at 4:49 PM Sawyer X <xsawyerx@gmail.com> wrote:

> Hi everyone,
>
> 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.
> * Major versions will be used for two purposes: 1. Turn on features
> and pragmas by default, 2. Remove syntax from the language.
> * Features will be guarded within a major version (that is, one *must*
> enable new features in 7.x with "use feature") but will be turned on
> in the next major version.
> * Perl 7.0.0 will be the first release. It will effectively be 5.32.0
> with a small number of pragmas (at the very least, strict and
> warnings) and features. The goal is to make it as trivial as possible
> to upgrade from 5.32.0 to 7.0.0.
> * Perl 5 will enter a long-term support window - 5+ years. Exact
> number not determined yet.
> * We intend to release 7.0.0 within a year. However, I am setting the
> goal of releasing it before the end of this year. I want to pave the
> way for 7.1.0, which will have the stable release of 7.2.0.
> * We will introduce utilities to help upgrade code to Perl 7. For
> example, if we were to add signatures by default in 7.0.0 (only *for
> example*), we will need code that helps users rewrite "sub foo ($)" as
> "sub foo :prototype($)".
> * We will also introduce a "compat::perl5" module, which will turn
> back the defaults of pragmas and features on 5.32.0. With this change,
> one could upgrade to Perl 7 binary immediately without changing the
> code. It allows a longer upgrade path.
> * We will also introduce a module to help fix up other modules. Such a
> module will especially help toolchain and infrastructure for CPAN
> manage the automatic upgrade or downgrade of modules without the user
> having to fix the code they are installing if it's incompatible.
>
> It would be hard to repeat everything in the talk, so I recommend
> watching the talk. The short and sweet is: We need to prioritize users
> who *write* Perl versus users who explicitly refuse or cannot update
> their code. In our current prioritization, we force all existing users
> and new users to manage the technical debt of previous generations.
>
> There is *a lot* to figure out at this point. We need to:
> * Update the internal code to support "use strict" and "use warnings".
> * Bump to 7.0.0.
> * Determine which pragmas and features will be enabled and turned on.
> * Determine how long we will support Perl version 5.
> * Determine the criteria for bumping major versions. Time might not be
> the best metric.
> * Create tickets for issues to be done so that the community could
> help. (People have already reached out, wanting to support this
> effort.)
> * Make sure we clarify what gets backported to Perl 5.32.x. Right now,
> it's the same criteria as every other maint release, except for a much
> longer time-frame.
> * Work on moving to 7.0.0 is already underway on the p7 branch here:
> https://github.com/atoomic/perl
>
> Additional comments:
> * Yearly releases for minor versions will continue as planned.
> * Monthly releases for dev versions will continue as planned.
> * See Perl 7.0.0 as 5.32.0 (+ some new defaults), 7.1.0 as 5.33.1.
> 7.2.0 will be akin to 5.34.0.
> * As exciting as 7.0.0 will be, it will mostly be there just to put us
> on our path. 8.0.0 will likely be much exciting.
> * There are notable stakeholders to the language which will be working
> with us to update their code to 7.0.0 defaults, to help understand the
> possible consequences.
> * We will need to rename the GitHub repo. That's okay because GitHub
> creates an automatic redirect for the URLs, including the GitHub clone
> paths.
> * /usr/bin/perl is owned by distributions. We are not in charge of it.
> We will be providing support to vendors and distributions and help
> them reach good decisions and move forward in the manner they choose.
>
> I apologize for not sharing this news earlier. We have been working on
> this plan for a very long time. p5p is a public mailing list, and we
> needed to manage the communication around this. Despite not being
> public, many people worked on it. Vital core developers, numerous core
> contributors, several significant stakeholders, vendors/distributions,
> and people with an in-depth history in Perl and the core code - were
> all involved. We have done a *lot* of work to get to where we are.
> While it's not a fully detailed change proposal, we have gone through
> quite a lot and tried to be very thorough while leaving room for
> things to now be openly discussed.
>
> Several threads will likely begin on the list to address specific
> issues listed above. I imagine this thread will itself receive a lot
> of responses and soon become sprawling. To manage this, I will open
> several threads, over several weeks, so we could have "waves" of
> discussions, instead of one monster thread in which we might quickly
> lose both our place and our focus. When discussing these topics, I
> request people to communicate mindfully and constructively.
>
> I want to thank everyone who helped work on this plan and shape it
> into what it is today. These are too many people to mention, but I
> want you to know I appreciate the effort, the time, the thorough
> reviews, the feedback, the ideas, and the solutions.
>
> Sawyer.
>
> [1] https://www.youtube.com/watch?v=6wPMh-3qYJM
>

--000000000000aed9a405a97774e8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>FYI, I have collected my core thoughts on the discuss=
ion here:=C2=A0<a href=3D"http://blogs.perl.org/users/grinnz/2020/07/perl-7=
-a-risk-benefit-analysis.html">http://blogs.perl.org/users/grinnz/2020/07/p=
erl-7-a-risk-benefit-analysis.html</a></div><div><br></div><div>-Dan</div><=
br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed,=
 Jun 24, 2020 at 4:49 PM Sawyer X &lt;<a href=3D"mailto:xsawyerx@gmail.com"=
>xsawyerx@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex">Hi everyone,<br>
<br>
A little while ago, I gave a talk[1] at The Perl Conference in the<br>
Cloud where I covered the Plan for Perl that includes the following<br>
significant changes:<br>
<br>
* We will begin using major versions again, starting with version 7.<br>
* Major versions will be used for two purposes: 1. Turn on features<br>
and pragmas by default, 2. Remove syntax from the language.<br>
* Features will be guarded within a major version (that is, one *must*<br>
enable new features in 7.x with &quot;use feature&quot;) but will be turned=
 on<br>
in the next major version.<br>
* Perl 7.0.0 will be the first release. It will effectively be 5.32.0<br>
with a small number of pragmas (at the very least, strict and<br>
warnings) and features. The goal is to make it as trivial as possible<br>
to upgrade from 5.32.0 to 7.0.0.<br>
* Perl 5 will enter a long-term support window - 5+ years. Exact<br>
number not determined yet.<br>
* We intend to release 7.0.0 within a year. However, I am setting the<br>
goal of releasing it before the end of this year. I want to pave the<br>
way for 7.1.0, which will have the stable release of 7.2.0.<br>
* We will introduce utilities to help upgrade code to Perl 7. For<br>
example, if we were to add signatures by default in 7.0.0 (only *for<br>
example*), we will need code that helps users rewrite &quot;sub foo ($)&quo=
t; as<br>
&quot;sub foo :prototype($)&quot;.<br>
* We will also introduce a &quot;compat::perl5&quot; module, which will tur=
n<br>
back the defaults of pragmas and features on 5.32.0. With this change,<br>
one could upgrade to Perl 7 binary immediately without changing the<br>
code. It allows a longer upgrade path.<br>
* We will also introduce a module to help fix up other modules. Such a<br>
module will especially help toolchain and infrastructure for CPAN<br>
manage the automatic upgrade or downgrade of modules without the user<br>
having to fix the code they are installing if it&#39;s incompatible.<br>
<br>
It would be hard to repeat everything in the talk, so I recommend<br>
watching the talk. The short and sweet is: We need to prioritize users<br>
who *write* Perl versus users who explicitly refuse or cannot update<br>
their code. In our current prioritization, we force all existing users<br>
and new users to manage the technical debt of previous generations.<br>
<br>
There is *a lot* to figure out at this point. We need to:<br>
* Update the internal code to support &quot;use strict&quot; and &quot;use =
warnings&quot;.<br>
* Bump to 7.0.0.<br>
* Determine which pragmas and features will be enabled and turned on.<br>
* Determine how long we will support Perl version 5.<br>
* Determine the criteria for bumping major versions. Time might not be<br>
the best metric.<br>
* Create tickets for issues to be done so that the community could<br>
help. (People have already reached out, wanting to support this<br>
effort.)<br>
* Make sure we clarify what gets backported to Perl 5.32.x. Right now,<br>
it&#39;s the same criteria as every other maint release, except for a much<=
br>
longer time-frame.<br>
* Work on moving to 7.0.0 is already underway on the p7 branch here:<br>
<a href=3D"https://github.com/atoomic/perl" rel=3D"noreferrer" target=3D"_b=
lank">https://github.com/atoomic/perl</a><br>
<br>
Additional comments:<br>
* Yearly releases for minor versions will continue as planned.<br>
* Monthly releases for dev versions will continue as planned.<br>
* See Perl 7.0.0 as 5.32.0 (+ some new defaults), 7.1.0 as 5.33.1.<br>
7.2.0 will be akin to 5.34.0.<br>
* As exciting as 7.0.0 will be, it will mostly be there just to put us<br>
on our path. 8.0.0 will likely be much exciting.<br>
* There are notable stakeholders to the language which will be working<br>
with us to update their code to 7.0.0 defaults, to help understand the<br>
possible consequences.<br>
* We will need to rename the GitHub repo. That&#39;s okay because GitHub<br=
>
creates an automatic redirect for the URLs, including the GitHub clone<br>
paths.<br>
* /usr/bin/perl is owned by distributions. We are not in charge of it.<br>
We will be providing support to vendors and distributions and help<br>
them reach good decisions and move forward in the manner they choose.<br>
<br>
I apologize for not sharing this news earlier. We have been working on<br>
this plan for a very long time. p5p is a public mailing list, and we<br>
needed to manage the communication around this. Despite not being<br>
public, many people worked on it. Vital core developers, numerous core<br>
contributors, several significant stakeholders, vendors/distributions,<br>
and people with an in-depth history in Perl and the core code - were<br>
all involved. We have done a *lot* of work to get to where we are.<br>
While it&#39;s not a fully detailed change proposal, we have gone through<b=
r>
quite a lot and tried to be very thorough while leaving room for<br>
things to now be openly discussed.<br>
<br>
Several threads will likely begin on the list to address specific<br>
issues listed above. I imagine this thread will itself receive a lot<br>
of responses and soon become sprawling. To manage this, I will open<br>
several threads, over several weeks, so we could have &quot;waves&quot; of<=
br>
discussions, instead of one monster thread in which we might quickly<br>
lose both our place and our focus. When discussing these topics, I<br>
request people to communicate mindfully and constructively.<br>
<br>
I want to thank everyone who helped work on this plan and shape it<br>
into what it is today. These are too many people to mention, but I<br>
want you to know I appreciate the effort, the time, the thorough<br>
reviews, the feedback, the ideas, and the solutions.<br>
<br>
Sawyer.<br>
<br>
[1] <a href=3D"https://www.youtube.com/watch?v=3D6wPMh-3qYJM" rel=3D"norefe=
rrer" target=3D"_blank">https://www.youtube.com/watch?v=3D6wPMh-3qYJM</a><b=
r>
</blockquote></div></div>

--000000000000aed9a405a97774e8--
0
grinnz
7/2/2020 3:56:19 PM
On 6/26/20 9:07 PM, Joseph Brenner wrote:
> [...]
>
> 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.


I'm working on a new thread in response to address the major points and 
recap on what our options are for moving forward, but I wanted to 
respond to this because I think it really matters.


I'm sorry you perceived my talk as if I had "classified" someone "who 
objects" to breaking compatibility as "an annoying conference attendee 
that harasses people." You misunderstood my point.


The point I was trying to make, which you don't need to agree with 
whatsoever, was that some people put a strain on a system. The strain 
might be worthwhile if the outcome from these people helps you meet your 
overall goal.


I presented situations with goals and personas that play on the curves 
of putting strain on a system and helping or not helping meet the goal.


There are lot of things that are different about these personas and the 
situations. In particular, someone who is looking to prevent a single 
change in Perl (even for eternity) is far - very far - from being the 
same as a person who harasses newcomers at conferences. If this is how 
you saw it, you profoundly misunderstood my comments. (I should note 
that some of the people who seek to keep Perl as static as possible are 
amazing people - personally and professionally - and I admire them as 
much as I disagree with them.)


Beyond this correction I needed to make, I want to clarify that the way 
you presented my position of people who are putting a strain on the 
system as those who simply care about backward compatibility is also 
incorrect and unhelpful to the discussion. You've expressed my position 
in a more extreme manner and it makes it very difficult to discuss "what 
is a fair strain on the system" when that point is presented as "anyone 
who puts *any* strain on the system."


The question is not whether we should aspire to retain or remove 
backward compatibility. We definitely want backward compatibility - and 
my record so far has shown this. The question is, to which degree do we 
want to retain it, and at which cost? What is the cost we accept? And if 
we want to change it, how do we mitigate it, which is what I feel most 
of the comments here - worded strongly or not - had been aspiring to 
highlight.


So far - and this is paramount for us to understand and deal with 
(because it's uncomfortable for most of us, myself included) - we never 
truly had this conversation. We never set the bar of "acceptable cost" 
except "if it's profoundly in the way of a feature, then maybe we'll 
rethink something." We never talked about the cost of the language and 
user-base deteriorating. The last time we've done this was Perl 6.


>
> [...]
>
> 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.
>>
0
xsawyerx
7/3/2020 1:00:44 PM
On 6/30/20 5:50 AM, Craig A. Berry wrote:
> On Mon, Jun 29, 2020 at 3:54 PM Kent Fredric <kentfredric@gmail.com> wrote:
>
>> the net result, whatever p5p does
> For the record, p5p has nothing to do with it.  The public mailing
> list appears to have been carefully and intentionally excluded from
> the first few months of Perl 7 development,



I understand how this seems, but I want to try and explain this:


* p5p has a record of being a very unfruitful place for in-depth public 
discussion which is not laser focused. This isn't necessarily a bad 
thing, but it is when we were discussing next Perl. It was also 
difficult to discuss other things. Instead, we found it suitable to 
start having face-to-face conversations that started as "p5h" (Perl 5 
Hackathon) and later renamed to the "Perl Core Summit" to which many 
people who work on Perl or are major stakeholders to Perl (including 
core developers, major company stakeholder representatives, tooling, and 
vendor maintainers) were invited. You are familiar with these events 
because you were also invited. We also wrote about them later online. 
They were officially sponsored by The Perl Foundation, though we reached 
out to companies for direct financial sponsorship.


* At the last Perl Core Summit, we had a conversation that was close to 
the "mug throwing" one that later led to Perl 6. Emotions were high, as 
was that famous event. My suggestion at the time was to utilize specific 
syntax (the "class {...}" keyword that Cor.pm suggests) to enable all 
modern defaults. Some were in favor, some not. We listed what we each 
find a "modern Perl" should have (from the existing available 
capabilities already in Perl). We also discussed possible problems and 
how to mitigate them.


* This conversation then led to a suggestion I made to the same list. 
The email suggested two options: 1. We keep Perl where it is. I quit and 
help find someone more suitable to help Perl stay put. 2. We change 
Perl. - I had made it very clear that this isn't "with me or without me" 
but rather "we - the group - need to make a decision on this topic. One 
decision I can help with, the other I would be terrible at." (Quick 
apology here to those who do wish to see me step down, no sarcasm.) 
Those who responded (not all did, I admit), whether on the list or 
personally to me, shared a vision of "let's move forward." This led to 
the proposal.


* Since the proposal is too large for p5p to properly evaluate - this 
thread is strong evidence of it - we had discussed it within that group. 
We then pulled more and more people into this. I also personally reached 
out to other people that are or were involved intimately with Perl to 
get their perspectives and thoughts. Larry was informed. I had a chat 
with Jesse, with David, and many others. I sincerely apologized I had 
not reached out to you.


* We also had several video chats in which we discussed the plan for 
hours. I think the first one passed the 4 hour window in a single video 
conference chat.


Now, I understand this seems like a no-starter and many think that any 
such plan should go to p5p, but I disagree. p5p is not the developers 
mailing list as it intends to be. In practice, it is a mailing list for 
those interested in the development, which the developers are part of. 
p5p has developers and people who don't develop. It has contributors and 
people who don't. It has people who actively discuss and lurkers alike. 
This thread is a good example of how difficult it is to have a focused 
conversation. (I don't want to color the entire thread, but some of it 
definitely is an example - not all). We all know how p5p is not good at 
moving forward, but looking at how to not.



>   and there have been very
> few and very incomplete and inconsistent replies here to the many
> questions and objections raised, and no response at all to a number of
> suggested modifications to the proposal that would make implementation
> of the stated goals saner and more achievable.


It takes me a long time to write a response because:


1. I have a day job. It is quite demanding at the moment.

2. I try to have a personal life, which includes having dinner, relaxing 
for a bit, and hopefully some sleep. (Nowadays, I rarely get to properly 
eat breakfast or lunch, if at all.)

3. I want to write thoughtful responses which avoid my 
default-and-stupid knee-jerk reaction which has been proving 
tremendously unhelpful over the years.

4. After hours of drafting (which can sometimes take more than several 
days), a series of additional emails are sent, which I then want to read.

5. I'm drawn into 1 on 1 conversations and group conversations with 
people - for which I'm thankful - in which we delve more into the 
topics. This proves much more beneficial for me hearing arguments than 
on the list, which I imagine people who are more list-oriented won't be 
happy to hear.


In short, it's difficult to engage in the way that the list - or some 
people on the list - would like people to engage in. I do apologize I am 
not able to keep up. I wish I could.


FWIW, I've set a goal to go over EVERY email of this thread today and 
I'll be writing a general response to address the key points, including 
those raised by Dave, Dan, and others.



[...]
0
xsawyerx
7/3/2020 1:42:07 PM
--00000000000048a71d05a98a5ceb
Content-Type: text/plain; charset="UTF-8"

On Fri, Jul 3, 2020 at 11:42 PM Sawyer X <xsawyerx@gmail.com> wrote:

FWIW, I've set a goal to go over EVERY email of this thread today and
> I'll be writing a general response to address the key points, including
> those raised by Dave, Dan, and others.
>

My intellectual capacity is not up to the task of evaluating all of the
concerns and counter-concerns that have so far been presented.
I would just like you to get on with whatever it is that you have planned,
so that I can get a handle on (and deal with) the adaptations that I need
to make to my CPAN modules.

Cheers,
Rob

--00000000000048a71d05a98a5ceb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Fri, Jul 3, 2020 at 11:42 PM Sawye=
r X &lt;<a href=3D"mailto:xsawyerx@gmail.com">xsawyerx@gmail.com</a>&gt; wr=
ote:</div><div dir=3D"ltr" class=3D"gmail_attr"><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">
FWIW, I&#39;ve set a goal to go over EVERY email of this thread today and <=
br>
I&#39;ll be writing a general response to address the key points, including=
 <br>
those raised by Dave, Dan, and others.<br></blockquote><div><br></div><div>=
My intellectual capacity is not up to the task of evaluating all of the con=
cerns and counter-concerns that have so far been presented.</div><div>I wou=
ld just like you to get on with whatever it is that you have planned, so th=
at I can get a handle on (and deal with) the adaptations that I need to mak=
e to my CPAN modules.</div><div><br></div><div>Cheers,</div><div>Rob</div><=
/div></div>

--00000000000048a71d05a98a5ceb--
0
sisyphus359
7/3/2020 2:29:42 PM
Hi Tom,


I understand this upset you greatly. I'm sorry about that. I'll try to 
address your points below best I can.



On 6/28/20 8:06 AM, Tom Ryder wrote:
> On Sat, Jun 27, 2020 at 06:20:38PM +0300, Sawyer X wrote:
>> We (and this "we" includes you, Leon) know for a very long time now 
>> that p5p, the mailing list, is not a very practical place to discuss 
>> major changes.
>
> My objection is that the community didn't get a chance to discuss the 
> changes at all, whether on perl5-porters or nay.  The changes were 
> announced after being decided by an apparently closed group---and were 
> already considered sufficiently finalised that a book has been 
> released by one of the group about preparing for the changes, 
> announced in the very same post.  It looks very much like a fait 
> accompli.
>
> <https://leanpub.com/preparing_for_perl7>


The community does not make this decision, for several reasons.


1. There is no definition of "the community." p5p attendance is not the 
community. In fact, some people who contribute to Perl are not even on 
the list, so it's not even the developers community. It is "a community" 
who is interested in the development and is willing to be on the list. 
Furthermore, many on the list don't bother reading it. I don't blame them.

2. The community does not have any specific representative that allows 
forming a single decision. It is a non-contingent group of people who 
each have their own interests and opinions. Some of them agree on some 
topics, many of them disagree on most, since it is such a wide variety 
of people, many of which with conflicting interests.

3. The community (whatever unknown and unorganized body of people it may 
be) are not the ones developing the language. You might argue that they 
are the ones using it, but various people have argued in the past that 
DarkPAN, specifically code that is not accounted for publicly, much of 
it written by people who are not in the communities, is a larger 
percentage of actually running Perl code. That means that the community 
isn't the biggest users necessarily.


Whoever you are referring to when stipulating "the community" (what I 
imagine you mean is p5p mailing list) is not the ones who determine 
where the language goes.


You are also mistaken in how you perceive who you referred to as "an 
apparently closed group" to which it was announced. Discussions ensued 
within this group who are, by far and large, the biggest core 
contributors to the language and major stakeholders, tooling, and 
vendors. I had explained in more detail in a response to Craig earlier 
today. I offer you the same apology of not reaching out to you as I 
genuinely offer to Craig. However, I disagree strongly with your points 
and the view you share above.


When we were preparing for announcement, we wanted to get organized and 
coordinated on the announcement. I can imagine this being upsetting to 
you if your definition of "get organized" includes a lengthy debate on 
p5p in which p5p approves the plans. What we did was reach out to people 
who communicate changes on Perl to the community at large. This was a 
day or two before the conference, if I recall correctly. The goal was 
for brian to be able to communicate quickly to the general public who 
read Perl.com and The Effective Perler to help spread the information in 
a clear way. The goal was for me to send the announcement immediately 
after the talk to p5p but unluck would have it and I wasn't able to do 
so. This is also why my announcement included an apology to this effect.


In short: People who work on the language and are heavily depending on 
it were involved in it. Announcement to media was made shortly prior to 
help major Perl outlets spread the message correctly.


I am aware this answer might not be enough for you. You might disagree 
with this path entirely. I understand that, but I cannot change it. It 
is how we chose to do it.



>
> Per my original question, would you please go into more detail on why 
> perl5-porters was intentionally insulated from this decision?


You can read this in my response both to Leon and Craig, as well as the 
comment above. If those answers are not sufficient, let me know.


Please do separate the reasons themselves from whether you agree with them.



>
> Could you also clarify why you felt it necessary to mislead the list 
> about the existence of these plans in the post I linked?
>
> <http://nntp.perl.org/group/perl.perl5.porters/257448>


I strongly resent the way you express this. There was no "misleading" of 
the list. It was correct that this option is available. I did not want 
to share yet that we will likely be doing this. At that time, it was 
still a strongly debated topic. Many conversations, even after the plan 
was reviewed and revised several times, raised perhaps changing it yet 
again (like to Perl 34). None of what I wrote in the email contradicts 
it or misleads.


If anything, my email had hinted at it, at best. To reiterate, I 
strongly resent how you are presenting this.



>
>> Everyone that was involved with this was in a shared file and 
>> viewable by everyone else. It was clear who was involved.
>
> Well, now that the changes the group intends to make are public, would 
> you tell *us* who was involved, and how they were selected?


To be completely open, the way you phrased this email, I am concerned 
that this will lead to more aggressive responses such as this one. Core 
Perl developers have endured enough aggressiveness for a lifetime. I 
will reach out to the group to get their explicit permission to publicly 
share who is in this group. I will note this group includes people who 
are frequent contributors (such as Dave Mitchell, Tony Cook, Karl 
Williamson, Jim Keenan, Todd Rinaldo, etc.), people from toolchain 
(Karen Etheridge, Leon Timmermans - who fits the previous group as 
well), and representatives of other vendors (primarily Debian).


Sawyer.
0
xsawyerx
7/3/2020 3:47:44 PM
Hi Tom,


I understand this upset you greatly. I'm sorry about that. I'll try to 
address your points below best I can.



On 6/28/20 8:06 AM, Tom Ryder wrote:
> On Sat, Jun 27, 2020 at 06:20:38PM +0300, Sawyer X wrote:
>> We (and this "we" includes you, Leon) know for a very long time now 
>> that p5p, the mailing list, is not a very practical place to discuss 
>> major changes.
>
> My objection is that the community didn't get a chance to discuss the 
> changes at all, whether on perl5-porters or nay.  The changes were 
> announced after being decided by an apparently closed group---and were 
> already considered sufficiently finalised that a book has been 
> released by one of the group about preparing for the changes, 
> announced in the very same post.  It looks very much like a fait 
> accompli.
>
> <https://leanpub.com/preparing_for_perl7>


The community does not make this decision, for several reasons:


1. There is no definition of "the community." p5p attendance is not the 
community. In fact, some people who contribute to Perl are not on the 
list, so it doesn't even represent the developers community. It is "a 
community" of people interested in the development and are willing to be 
on the list. Furthermore, many on the list don't bother reading it, 
whether because it's boring, annoying, or too long.

2. The community does not have any specific representative that allows 
forming a single decision. It is a group of people who each have their 
own interests and opinions. Some of them agree on certain topics, many 
of them disagree on most, since it is such a wide variety of people, 
many of which with conflicting interests.

3. The community (whatever unknown and unorganized body of people it may 
be) are not the ones developing the language. You might argue that they 
are the ones using it, but various people have argued in the past that 
DarkPAN, specifically code that is not accounted for publicly, much of 
it written by people who are not in the community, is a larger 
percentage of production Perl code. That means that the community isn't 
the biggest user-base necessarily.


Whoever you are referring to when stipulating "the community" (what I 
imagine you mean is p5p mailing list) is not the ones who determine 
where the language goes.


You are also mistaken in how you perceive who you referred to as "an 
apparently closed group" to which it was announced. Discussions ensued 
within this group who are, by far and large, the biggest core 
contributors to the language and major stakeholders, tooling, and 
vendors. I had explained in more detail in a response to Craig earlier 
today. I offer you the same apology of not reaching out to you as I 
genuinely offer to Craig. However, I disagree strongly with your points 
and the view you share above.


When we were preparing for announcement, we wanted to get organized and 
coordinated on the announcement. I can imagine this being unacceptable 
to you if your definition of "get organized" includes a lengthy debate 
on p5p in which p5p approves the plans, but this wasn't my definition. 
We (this includes myself, people who worked on the plan, and TPF) 
reached out to people who communicate changes on Perl to the community 
at large. This was a day or two before the conference, if I recall 
correctly. The goal was for brian to be able to communicate quickly to 
the general public who read Perl.com and The Effective Perler to help 
spread the information in a clear way. I intended to send the 
announcement to p5p immediately after the talk but (un)luck would have 
it and I wasn't able to do so. This is also why my announcement included 
an apology to this effect.


In short: People who work on the language and are heavily depending on 
it were involved in it. Announcement to media was made shortly prior to 
help major Perl outlets spread the message correctly.


I am aware this answer might not be enough for you. You might disagree 
with this path entirely. I understand that, but I cannot change it. It 
is how we chose to do it.



>
> Per my original question, would you please go into more detail on why 
> perl5-porters was intentionally insulated from this decision?


You can read this in my response both to Leon and Craig, as well as the 
comment above. If those answers are not sufficient, let me know.


Please do separate the reasons themselves from whether you agree with them.



>
> Could you also clarify why you felt it necessary to mislead the list 
> about the existence of these plans in the post I linked?
>
> <http://nntp.perl.org/group/perl.perl5.porters/257448>


I strongly resent the way you express this. There was no "misleading" of 
the list. It was correct that this option is available. I did not want 
to share yet that we will likely be taking this path. This is also why I 
abstained from the thread best I could. At that time, it was still a 
strongly debated topic. Many conversations, even after the plan was 
reviewed and revised several times, raised perhaps changing it yet again 
(like to Perl 34). None of what I wrote in the email contradicts it or 
misleads.


If anything, my email had hinted at it, at best. To reiterate, I 
strongly resent how you are characterizing my response as deceiving.



>
>> Everyone that was involved with this was in a shared file and 
>> viewable by everyone else. It was clear who was involved.
>
> Well, now that the changes the group intends to make are public, would 
> you tell *us* who was involved, and how they were selected?


To be completely fair, based on your email, I am concerned that this 
will lead to more aggressive responses to these people. Core Perl 
developers have endured enough aggressiveness for a lifetime. I will 
reach out to the group to get their explicit permission to publicly 
share who is in this group. I will note this group includes people who 
are frequent contributors (such as Dave Mitchell, Tony Cook, Karl 
Williamson, Jim Keenan, Todd Rinaldo, etc.), people from toolchain 
(Karen Etheridge, Leon Timmermans - who fits the previous group as 
well), and representatives of other vendors (primarily Debian).


Sawyer.
0
xsawyerx
7/3/2020 3:58:50 PM
(Sorry for late replies; I'm re-reading all the thread again to find
things I missed the first time)

On Mon, 29 Jun 2020 04:08:06 +0200
Leon Timmermans <fawaka@gmail.com> wrote:

> I may have known much more than most, but what I did not know is that
> this would be communicated to the outside world as a done deal. The
> Plan for Perl document certainly didn't say that.

+1 to this.

When Sawyer first raised this to the small select group of us a few
months ago, I was initially sceptical on the idea mostly for a
general fear of many of the kinds of breakages that people are
suggesting now - though at the time I hadn't thought of many of the
specifics (e.g. I hadn't foreseen at the time such problems as PPI/PPR
or github syntax highlight). I was also persuaded by the idea that
timeline will fix everything - we'd have years before we'd *force*
7-semantics onto everyone. And just maybe those years might be enough
to work out solutions to many of these issues.

I cautiously gave an agreement on that basis. I am not in the habit of
publicly disclosing private conversations, but I will paraphrase the
words I said:

> I am happy with a plan to release 5.32, 5.34, etc as normal, with a
> dual statement that we are working on a major version 7 which will
> come out in at least 2 years. Possibly longer. No shorter.

After that suggestion, there were some more messages from some
concerned folks who thought even 2 years would be quite short; and I
agreed. Maybe safest to say "3 to 5". But certainly, the idea was to
keep the 5.3x train going as well alongside the publicly-visible
proto-7, ready for a release some time in the future. I also felt that
there was agreement from Sawyer on my point of "at least 2 years".


The announcement given at CIC was "this year, by Christmas". That's 6
months away. This is a sudden contraction of that timeline into a
period much shorter than my conditional approval was based on.

If we are saying that 7.0.0 is out by Christmas 2020 and there will
be no more 5.3x then I am no longer on-board with this idea.

-- 
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk      |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/
0
leonerd
7/3/2020 4:36:10 PM
On Sat, 27 Jun 2020 01:20:06 -0700
Darren Duncan <darren@darrenduncan.net> wrote:

> 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.

Yes - some excellent thoughts there. I entirely agree. More things
should be upfront and explicit about versioning. Even our good old
friend HTTP starts off with

  GET / HTTP/1.1

So I don't think it's a bad model to consider.

> 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.

Cautiously agree. Obviously this is going to require a fair amount of
deprecation time before it becomes mandatory, but I could foresee a
world in which every .pm file starts off with "use N" for some N, and
that would be no bad thing.

> 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.

+1

> 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.
....

> 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.

So much more +1.

I overall agree with everything you've said. I've trimmed the above
reply to only the most relevant parts, but a lot of good stuff there.
I'm sorry I missed it first time around but I discovered it on
re-reading the list a second time.

-- 
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk      |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/
0
leonerd
7/3/2020 4:53:05 PM
[top posted]

Can you be more brief in future? This is a lot of content, and a
shortage of actual information. It's a waste of my time and a headache
to read this shit.

On Sat, 4 Jul 2020 at 03:47, Sawyer X <xsawyerx@gmail.com> wrote:
>
> Hi Tom,
>
>
> I understand this upset you greatly. I'm sorry about that. I'll try to
> address your points below best I can.
>
>
>
> On 6/28/20 8:06 AM, Tom Ryder wrote:
> > On Sat, Jun 27, 2020 at 06:20:38PM +0300, Sawyer X wrote:
> >> We (and this "we" includes you, Leon) know for a very long time now
> >> that p5p, the mailing list, is not a very practical place to discuss
> >> major changes.
> >
> > My objection is that the community didn't get a chance to discuss the
> > changes at all, whether on perl5-porters or nay.  The changes were
> > announced after being decided by an apparently closed group---and were
> > already considered sufficiently finalised that a book has been
> > released by one of the group about preparing for the changes,
> > announced in the very same post.  It looks very much like a fait
> > accompli.
> >
> > <https://leanpub.com/preparing_for_perl7>
>
>
> The community does not make this decision, for several reasons.
>
>
> 1. There is no definition of "the community." p5p attendance is not the
> community. In fact, some people who contribute to Perl are not even on
> the list, so it's not even the developers community. It is "a community"
> who is interested in the development and is willing to be on the list.
> Furthermore, many on the list don't bother reading it. I don't blame them.
>
> 2. The community does not have any specific representative that allows
> forming a single decision. It is a non-contingent group of people who
> each have their own interests and opinions. Some of them agree on some
> topics, many of them disagree on most, since it is such a wide variety
> of people, many of which with conflicting interests.
>
> 3. The community (whatever unknown and unorganized body of people it may
> be) are not the ones developing the language. You might argue that they
> are the ones using it, but various people have argued in the past that
> DarkPAN, specifically code that is not accounted for publicly, much of
> it written by people who are not in the communities, is a larger
> percentage of actually running Perl code. That means that the community
> isn't the biggest users necessarily.
>
>
> Whoever you are referring to when stipulating "the community" (what I
> imagine you mean is p5p mailing list) is not the ones who determine
> where the language goes.
>
>
> You are also mistaken in how you perceive who you referred to as "an
> apparently closed group" to which it was announced. Discussions ensued
> within this group who are, by far and large, the biggest core
> contributors to the language and major stakeholders, tooling, and
> vendors. I had explained in more detail in a response to Craig earlier
> today. I offer you the same apology of not reaching out to you as I
> genuinely offer to Craig. However, I disagree strongly with your points
> and the view you share above.
>
>
> When we were preparing for announcement, we wanted to get organized and
> coordinated on the announcement. I can imagine this being upsetting to
> you if your definition of "get organized" includes a lengthy debate on
> p5p in which p5p approves the plans. What we did was reach out to people
> who communicate changes on Perl to the community at large. This was a
> day or two before the conference, if I recall correctly. The goal was
> for brian to be able to communicate quickly to the general public who
> read Perl.com and The Effective Perler to help spread the information in
> a clear way. The goal was for me to send the announcement immediately
> after the talk to p5p but unluck would have it and I wasn't able to do
> so. This is also why my announcement included an apology to this effect.
>
>
> In short: People who work on the language and are heavily depending on
> it were involved in it. Announcement to media was made shortly prior to
> help major Perl outlets spread the message correctly.
>
>
> I am aware this answer might not be enough for you. You might disagree
> with this path entirely. I understand that, but I cannot change it. It
> is how we chose to do it.
>
>
>
> >
> > Per my original question, would you please go into more detail on why
> > perl5-porters was intentionally insulated from this decision?
>
>
> You can read this in my response both to Leon and Craig, as well as the
> comment above. If those answers are not sufficient, let me know.
>
>
> Please do separate the reasons themselves from whether you agree with them.
>
>
>
> >
> > Could you also clarify why you felt it necessary to mislead the list
> > about the existence of these plans in the post I linked?
> >
> > <http://nntp.perl.org/group/perl.perl5.porters/257448>
>
>
> I strongly resent the way you express this. There was no "misleading" of
> the list. It was correct that this option is available. I did not want
> to share yet that we will likely be doing this. At that time, it was
> still a strongly debated topic. Many conversations, even after the plan
> was reviewed and revised several times, raised perhaps changing it yet
> again (like to Perl 34). None of what I wrote in the email contradicts
> it or misleads.
>
>
> If anything, my email had hinted at it, at best. To reiterate, I
> strongly resent how you are presenting this.
>
>
>
> >
> >> Everyone that was involved with this was in a shared file and
> >> viewable by everyone else. It was clear who was involved.
> >
> > Well, now that the changes the group intends to make are public, would
> > you tell *us* who was involved, and how they were selected?
>
>
> To be completely open, the way you phrased this email, I am concerned
> that this will lead to more aggressive responses such as this one. Core
> Perl developers have endured enough aggressiveness for a lifetime. I
> will reach out to the group to get their explicit permission to publicly
> share who is in this group. I will note this group includes people who
> are frequent contributors (such as Dave Mitchell, Tony Cook, Karl
> Williamson, Jim Keenan, Todd Rinaldo, etc.), people from toolchain
> (Karen Etheridge, Leon Timmermans - who fits the previous group as
> well), and representatives of other vendors (primarily Debian).
>
>
> Sawyer.



-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL
0
kentfredric
7/3/2020 5:00:14 PM
On Fri, Jul 3, 2020 at 8:42 AM Sawyer X <xsawyerx@gmail.com> wrote:
>
>
> On 6/30/20 5:50 AM, Craig A. Berry wrote:
> > On Mon, Jun 29, 2020 at 3:54 PM Kent Fredric <kentfredric@gmail.com> wrote:
> >
> >> the net result, whatever p5p does
> > For the record, p5p has nothing to do with it.  The public mailing
> > list appears to have been carefully and intentionally excluded from
> > the first few months of Perl 7 development,
>
>
>
> I understand how this seems, but I want to try and explain this:

Thanks for the reply.  I think I already understand how you see the
mailing list.

> * p5p has a record of being a very unfruitful place for in-depth public
> discussion which is not laser focused.
....
> * Since the proposal is too large for p5p to properly evaluate - this
> thread is strong evidence of it - we had discussed it within that group.
....
> Now, I understand this seems like a no-starter and many think that any
> such plan should go to p5p, but I disagree. p5p is not the developers
> mailing list as it intends to be. In practice, it is a mailing list for
> those interested in the development, which the developers are part of.
....
> In short, it's difficult to engage in the way that the list - or some
> people on the list - would like people to engage in. I do apologize I am
> not able to keep up. I wish I could.

However difficult it is to engage the mailing list (and I've been an
observer of at least some of those difficulties for a couple of
decades), it's never been considered optional.  This is partly
convention and tradition, but not just of the "we've always done it
this way" type but more because there's never been an equally
efficient (if messy) mechanism for providing transparency and keeping
the "open" in open source. My reading of L<perlpolicy/GOVERNANCE> is
that making major changes to Perl actually requires consulting p5p
(what Larry calls the legislative branch).
0
craig
7/3/2020 5:06:10 PM
On Fri, 03 Jul 2020 18:53:05 +0200, Paul "LeoNerd" Evans <leonerd@leonerd.org.uk> wrote:

> On Sat, 27 Jun 2020 01:20:06 -0700
> Darren Duncan <darren@darrenduncan.net> wrote:
>
>> 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.
>
> Yes - some excellent thoughts there. I entirely agree. More things
> should be upfront and explicit about versioning. Even our good old
> friend HTTP starts off with
>
>   GET / HTTP/1.1
>
> So I don't think it's a bad model to consider.
>
>> 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.
>
> Cautiously agree. Obviously this is going to require a fair amount of
> deprecation time before it becomes mandatory, but I could foresee a
> world in which every .pm file starts off with "use N" for some N, and
> that would be no bad thing.
>
>> 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.
>
> +1
>
>> 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.
> ...
>
>> 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.
>
> So much more +1.
>
> I overall agree with everything you've said. I've trimmed the above
> reply to only the most relevant parts, but a lot of good stuff there.
> I'm sorry I missed it first time around but I discovered it on
> re-reading the list a second time.

I wholeheartedly agree with all of this.

-- 
With regards,
Christian Walde
0
walde
7/3/2020 5:17:08 PM
On Thu, 2 Jul 2020 11:56:19 -0400
Dan Book <grinnz@gmail.com> wrote:

> FYI, I have collected my core thoughts on the discussion here:
> http://blogs.perl.org/users/grinnz/2020/07/perl-7-a-risk-benefit-analysis.html

(to copy my comment on the post, for posterity of the mailing list)

A huge +1 to all of this. Thank you for articulating it so coherently. I
am in entire agreement with this whole idea.

-- 
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk      |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/
0
leonerd
7/3/2020 5:18:56 PM
On Tue, 30 Jun 2020 at 13:37, Paul "LeoNerd" Evans
<leonerd@leonerd.org.uk> wrote:
>
> On Tue, 30 Jun 2020 12:02:10 +0200
> Salvador Fandi=C3=B1o <sfandino@gmail.com> wrote:
>
> > It you want to avoid the "use v7;" line, then you should be able to
> > tell perl explicitly in some way you want the 7 semantics. The only
> > sane way I can see for that, is using different file terminations.
> > I.e. p7, pl7, pm7, t7.
> >
> > And when perl 8 comes out, you can switch to p8, pl8, etc.
>
> This would be an odd suggestion.
>
> I believe the main motivation for people saying they don't want to
> "use v7" is precisely to avoid having to update to "use v8" and so on
> in the future; having to chase the latest-and-greatest by making a
> single character change to their code every decade or so.

Personally I do not see that or pleasing those people as the reason
for doing it.

I see it as simply providing a new answer to what version perl is
expecting when it starts parsing. Eg, all the stuff "above" the use
statement.

As long as the rule is "perl 5" variant, we have a problem that anyone
create a document that is a mix of a 5 and something else.

We want to eventually ditch the perl 5 variant, and move to a saner
perl 7 or 8 variant, which means that ast some point we want the
parser to not know about 5 AT ALL, except when it throws exceptions.
Making the rule be "the parser starts out expecting perl 5" simply
does not make sense, for *any* version. Making the rule be "the parser
starts out expecting perl $Latest" does.

The people that use this to get the latest version are just making
their lives difficult. Nobody sane should do it on purpose.

cheers,
Yves


--=20
perl -Mre=3Ddebug -e "/just|another|perl|hacker/"
0
demerphq
7/3/2020 5:22:03 PM
On Fri, 3 Jul 2020 at 19:19, Paul "LeoNerd" Evans
<leonerd@leonerd.org.uk> wrote:
>
> On Thu, 2 Jul 2020 11:56:19 -0400
> Dan Book <grinnz@gmail.com> wrote:
>
> > FYI, I have collected my core thoughts on the discussion here:
> > http://blogs.perl.org/users/grinnz/2020/07/perl-7-a-risk-benefit-analysis.html
>
> (to copy my comment on the post, for posterity of the mailing list)
>
> A huge +1 to all of this. Thank you for articulating it so coherently. I
> am in entire agreement with this whole idea.

So if I understand you both correctly, we have to continue to support
all perl 5 code forever?

Because that is what I understand you to be saying.

To me this question comes down to a simple technical question: what
language variant does the parser start out expecting before it sees
the "use v7" line?

If we say "perl 5" then we have to support all of perl 5 forever don't we?

Doesn't that kind of er, stand in the way of not supporting perl 5 forever?

Doesn't it make a lot more sense to say "prior to seeing a C<use
v$DIGIT;> statement the parser will be expecting the *latest* variant
of the language"? Isn't the certainty of that the only sane choice if
we are ever to deprecate older variant code?

cheers,
Yves
0
demerphq
7/3/2020 5:33:20 PM
On Fri, 03 Jul 2020 19:22:03 +0200, demerphq <demerphq@gmail.com> wrote:=


> On Tue, 30 Jun 2020 at 13:37, Paul "LeoNerd" Evans
> <leonerd@leonerd.org.uk> wrote:
>>
>> On Tue, 30 Jun 2020 12:02:10 +0200
>> Salvador Fandi=F1o <sfandino@gmail.com> wrote:
>>
>> > It you want to avoid the "use v7;" line, then you should be able to=

>> > tell perl explicitly in some way you want the 7 semantics. The only=

>> > sane way I can see for that, is using different file terminations.
>> > I.e. p7, pl7, pm7, t7.
>> >
>> > And when perl 8 comes out, you can switch to p8, pl8, etc.
>>
>> This would be an odd suggestion.
>>
>> I believe the main motivation for people saying they don't want to
>> "use v7" is precisely to avoid having to update to "use v8" and so on=

>> in the future; having to chase the latest-and-greatest by making a
>> single character change to their code every decade or so.
>
> Personally I do not see that or pleasing those people as the reason
> for doing it.
>
> I see it as simply providing a new answer to what version perl is
> expecting when it starts parsing. Eg, all the stuff "above" the use
> statement.
>
> As long as the rule is "perl 5" variant, we have a problem that anyone=

> create a document that is a mix of a 5 and something else.
>
> We want to eventually ditch the perl 5 variant, and move to a saner
> perl 7 or 8 variant, which means that ast some point we want the
> parser to not know about 5 AT ALL, except when it throws exceptions.
> Making the rule be "the parser starts out expecting perl 5" simply
> does not make sense, for *any* version. Making the rule be "the parser=

> starts out expecting perl $Latest" does.
>
> The people that use this to get the latest version are just making
> their lives difficult. Nobody sane should do it on purpose.

That circles back to the question of what you envision to happen in the =
future with unversioned perl 5 code. (Language fork, empower modules@, f=
rankenstein via CPAN.pm, etc..)

It also is completely orthogonal to the question of use 7; being mandato=
ry or not. (You can still have it parse it as perl 7, and fail with ETOO=
VAGUE at a lack of version at end of parse or before any other parse err=
or is thrown.)

-- =

With regards,
Christian Walde
0
walde
7/3/2020 5:34:09 PM
On Fri, 03 Jul 2020 19:33:20 +0200, demerphq <demerphq@gmail.com> wrote:

> On Fri, 3 Jul 2020 at 19:19, Paul "LeoNerd" Evans
> <leonerd@leonerd.org.uk> wrote:
>>
>> On Thu, 2 Jul 2020 11:56:19 -0400
>> Dan Book <grinnz@gmail.com> wrote:
>>
>> > FYI, I have collected my core thoughts on the discussion here:
>> > http://blogs.perl.org/users/grinnz/2020/07/perl-7-a-risk-benefit-analysis.html
>>
>> (to copy my comment on the post, for posterity of the mailing list)
>>
>> A huge +1 to all of this. Thank you for articulating it so coherently. I
>> am in entire agreement with this whole idea.
>
> So if I understand you both correctly, we have to continue to support
> all perl 5 code forever?
>
> Because that is what I understand you to be saying.
>
> To me this question comes down to a simple technical question: what
> language variant does the parser start out expecting before it sees
> the "use v7" line?
>
> If we say "perl 5" then we have to support all of perl 5 forever don't we?
>
> Doesn't that kind of er, stand in the way of not supporting perl 5 forever?
>
> Doesn't it make a lot more sense to say "prior to seeing a C<use
> v$DIGIT;> statement the parser will be expecting the *latest* variant
> of the language"? Isn't the certainty of that the only sane choice if
> we are ever to deprecate older variant code?
>
> cheers,
> Yves
>

As mentioned in the reply i sent just previously: You can have versions mandatory and still have the interpreter "forget" Perl 5.

-- 
With regards,
Christian Walde
0
walde
7/3/2020 5:35:54 PM
On Fri, 3 Jul 2020 19:22:03 +0200
demerphq <demerphq@gmail.com> wrote:

> We want to eventually ditch the perl 5 variant, and move to a saner
> perl 7 or 8 variant, which means that ast some point we want the
> parser to not know about 5 AT ALL, except when it throws exceptions.
> Making the rule be "the parser starts out expecting perl 5" simply
> does not make sense, for *any* version. Making the rule be "the parser
> starts out expecting perl $Latest" does.

Right now, we start off in "version 5" mode until we see a
"use VERSION" which alters the idea. We should *strongly encourage*
everyone to be explicit with their version statements. It is a shame
more people haven't been using "use VERSION" so far, though that can be
explained by the fact it isn't very powerful yet. Suggestions have been
made that it should "use warnings" and so on - these could definitely
help.


How about this as an idea:

At some point in the future, the semantics changes very slightly to:
We start off in "guess probably version 5" mode, wherein any
non-whitespace/comment syntax we see other than an explicit "use
VERSION" statement provides a warning that the user didn't declare
their version requirement. We'll continue presuming v5 for now unless
they asked for something else, but that warning gives people a hint, a
nudge that they should be explicit now.

At some later point beyond that, it becomes a hard error. We can now
delete all the old version-5 compat code in the core because we know
(from the previous deprecation round and warnings) that everyone has
been explicit on their version requirements.

Plus now, since we know everyone is being explicit in their version
requirements, we can continue to do the same trick further down the
line; maybe at a hypothetical version 15 a few decades from now people
have to start dropping version 7. That's all still fine, because
everyone declared the version they wanted.


This isn't a new idea, various folks have already suggested it already:

  Dave Mitchell -
  https://www.nntp.perl.org/group/perl.perl5.porters/2020/06/msg257566.html

  BooK -
  https://www.nntp.perl.org/group/perl.perl5.porters/2020/06/msg257567.html

  Darren Duncan -
  https://www.nntp.perl.org/group/perl.perl5.porters/2020/06/msg257666.html
  https://www.nntp.perl.org/group/perl.perl5.porters/2020/06/msg257607.html

  with whom myself and Christian Walde agree -
  https://www.nntp.perl.org/group/perl.perl5.porters/2020/07/msg257781.html
  https://www.nntp.perl.org/group/perl.perl5.porters/2020/07/msg257784.html

-- 
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk      |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/
0
leonerd
7/3/2020 5:38:18 PM
On Fri, 3 Jul 2020 19:33:20 +0200
demerphq <demerphq@gmail.com> wrote:

> So if I understand you both correctly, we have to continue to support
> all perl 5 code forever?
> 
> Because that is what I understand you to be saying.

Then you misunderstand. That is not at all what I am arguing.

> To me this question comes down to a simple technical question: what
> language variant does the parser start out expecting before it sees
> the "use v7" line?
> 
> If we say "perl 5" then we have to support all of perl 5 forever
> don't we?
> 
> Doesn't that kind of er, stand in the way of not supporting perl 5
> forever?

I'm saying that *right now* it should continue to behave like Perl 5,
but after a suitable announcement period it should start giving
"version is ambiguous" warnings. At some further point after that we
can have it be an outright error for there not to be a version
declaration, at which point we're free to cut off an older version of
perl if we so wish.

And by forcing everyone to have declared their version requirements by
then we can do a simple grep for "use v5" across all of CPAN to gain a
very easy simple metric on how much actual CPAN code is actually still
using v5. When we feel that number is small enough - or the remaining
outliers unimportant enough - we can cut it off.

> Doesn't it make a lot more sense to say "prior to seeing a C<use
> v$DIGIT;> statement the parser will be expecting the *latest* variant
> of the language"? Isn't the certainty of that the only sane choice if
> we are ever to deprecate older variant code?

No. I'd say it makes more sense to say "prior to seeing a C<use
v$DIGIT;> statement the parser will start off in ambiguous-guessing-5
variant, which provokes a warning when it starts to parse real code".
Isn't the certainty of knowing the author is now strongly encouraged to
declare their version requirement the only sane choice if we are ever
to deprecate older variant code while knowing it is safe to do so?

-- 
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk      |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/
0
leonerd
7/3/2020 5:47:37 PM
On Fri, 26 Jun 2020 at 22:54, Craig A. Berry <craig.a.berry@gmail.com> wrote:
>
> On Fri, Jun 26, 2020 at 1:25 PM demerphq <demerphq@gmail.com> wrote:
> >
> > On Fri, 26 Jun 2020 at 18:03, Dave Mitchell <davem@iabyn.com> wrote:
> > > So for example,  running a plain perl script using a perl7 interpreter is
> > > as if the following lines had been injected at the top of the script:
> > >
> > >     use warnings;
> > >     use strict;
> > >     use feature 'signatures';
> > >     no feature 'indirect';
> > >     ... etc ...
> > >
> > > is that the same as your understanding?
> >
> > Depends on your definition of "as if".
> >
> > If it means "exactly the same as", then no, that isnt my expectation.
> >
> > If it means "produces the same practical outcome for the developer" then yes.
> >
> > Meaning that if my understanding of what "use strict;" will imply is
> > correct then we would probably not make the v7 semantics actually
> > trigger strict.pm, the latter would be used only in legacy code.
>
> This is super confusing to me.  I think I hear you saying that 7.0.0
> will have strictness enforced by default, albeit not via strict.pm.
> OK.  But then you also said you have the impression that actually
> putting "use strict;" at the top of your code will disable the v7
> feature bundle and be equivalent to the backward compatibility pragma
> but with strict.pm loaded.  Is that really what you are saying?  That
> means everyone who has ever followed the advice to enable strictness
> will have to remove the explicit "use strict;" from their code in
> order to get all the new on-by-default features. That does not sound
> like the principle of least surprise to me; the v7 semantics would be
> invisible to well-maintained software that follows coding standards,
> and a big, incompatible wallop to everything else.  Hopefully I'm just
> missing a clue here somewhere and have not understood what is really
> being proposed.

Sorry, I got run over by a bus at work metaphorically at an
inconvenient time for this thread and there are so many posts I have
no idea what is going on properly so I dont know if this has already
been responded to, or if im even right, but what I understood was that
if you use strict inside of the scope of a use v7 (or later) then the
use strict would be a no-op effectively, and not change what version
is expected.

---
package Foo; # parsed as v-latest but it doesn't matter.
use v7; # give me well defined semantics
use strict; # no op
---

vs:

---
package Foo; # parsed as v-latest but it doesn't  matter.
use strict; # implied 'use v5;'
---

Does that make more sense? To me that means most code would not break.

cheers,
Yves




-- 
perl -Mre=debug -e "/just|another|perl|hacker/"
0
demerphq
7/3/2020 5:47:45 PM
On Fri, 3 Jul 2020 at 19:35, Christian Walde <walde.christian@gmail.com> wrote:
>
> On Fri, 03 Jul 2020 19:33:20 +0200, demerphq <demerphq@gmail.com> wrote:
>
> > On Fri, 3 Jul 2020 at 19:19, Paul "LeoNerd" Evans
> > <leonerd@leonerd.org.uk> wrote:
> >>
> >> On Thu, 2 Jul 2020 11:56:19 -0400
> >> Dan Book <grinnz@gmail.com> wrote:
> >>
> >> > FYI, I have collected my core thoughts on the discussion here:
> >> > http://blogs.perl.org/users/grinnz/2020/07/perl-7-a-risk-benefit-analysis.html
> >>
> >> (to copy my comment on the post, for posterity of the mailing list)
> >>
> >> A huge +1 to all of this. Thank you for articulating it so coherently. I
> >> am in entire agreement with this whole idea.
> >
> > So if I understand you both correctly, we have to continue to support
> > all perl 5 code forever?
> >
> > Because that is what I understand you to be saying.
> >
> > To me this question comes down to a simple technical question: what
> > language variant does the parser start out expecting before it sees
> > the "use v7" line?
> >
> > If we say "perl 5" then we have to support all of perl 5 forever don't we?
> >
> > Doesn't that kind of er, stand in the way of not supporting perl 5 forever?
> >
> > Doesn't it make a lot more sense to say "prior to seeing a C<use
> > v$DIGIT;> statement the parser will be expecting the *latest* variant
> > of the language"? Isn't the certainty of that the only sane choice if
> > we are ever to deprecate older variant code?
> >
> > cheers,
> > Yves
> >
>
> As mentioned in the reply i sent just previously: You can have versions mandatory and still have the interpreter "forget" Perl 5.

I'm still trying to find that mail. Really. There are so many threads
involved I haven't found it yet. But I don't get it really.

cheers,
Yves


-- 
perl -Mre=debug -e "/just|another|perl|hacker/"
0
demerphq
7/3/2020 5:57:21 PM
On Sat, 4 Jul 2020 at 05:47, Paul "LeoNerd" Evans
<leonerd@leonerd.org.uk> wrote:

>
> And by forcing everyone to have declared their version requirements by
> then we can do a simple grep for "use v5" across all of CPAN to gain a
> very easy simple metric on how much actual CPAN code is actually still
> using v5. When we feel that number is small enough - or the remaining
> outliers unimportant enough - we can cut it off.

You realise of course this will never factor for "real world perl
deployments", nor any of the stuff outside of CPAN, but are in use in
critical paths, some, in critical open source code.

Measuring using CPAN is like measuring an iceberg using its height
above the waterline.

-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL
0
kentfredric
7/3/2020 6:00:34 PM
On Fri, 3 Jul 2020 19:57:21 +0200
demerphq <demerphq@gmail.com> wrote:

> On Fri, 3 Jul 2020 at 19:35, Christian Walde
> <walde.christian@gmail.com> wrote:
> > As mentioned in the reply i sent just previously: You can have
> > versions mandatory and still have the interpreter "forget" Perl 5.  
> 
> I'm still trying to find that mail. Really. There are so many threads
> involved I haven't found it yet. But I don't get it really.

https://www.nntp.perl.org/group/perl.perl5.porters/2020/07/msg257788.html

-- 
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk      |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/
0
leonerd
7/3/2020 6:02:29 PM
On Fri, 03 Jul 2020 20:02:29 +0200, Paul "LeoNerd" Evans <leonerd@leonerd.org.uk> wrote:

> On Fri, 3 Jul 2020 19:57:21 +0200
> demerphq <demerphq@gmail.com> wrote:
>
>> On Fri, 3 Jul 2020 at 19:35, Christian Walde
>> <walde.christian@gmail.com> wrote:
>> > As mentioned in the reply i sent just previously: You can have
>> > versions mandatory and still have the interpreter "forget" Perl 5.
>>
>> I'm still trying to find that mail. Really. There are so many threads
>> involved I haven't found it yet. But I don't get it really.
>
> https://www.nntp.perl.org/group/perl.perl5.porters/2020/07/msg257788.html

Also:

https://www.nntp.perl.org/group/perl.perl5.porters/2020/07/msg257790.html

-- 
With regards,
Christian Walde
0
walde
7/3/2020 6:03:25 PM
On Sat, 4 Jul 2020 06:00:34 +1200
Kent Fredric <kentfredric@gmail.com> wrote:

> You realise of course this will never factor for "real world perl
> deployments", nor any of the stuff outside of CPAN, but are in use in
> critical paths, some, in critical open source code.
> 
> Measuring using CPAN is like measuring an iceberg using its height
> above the waterline.

Oh that is certainly true. I'd hope we use more than *just* a quick
grep of CPAN to decide on it. But nevertheless it becomes one signal
among many we can use.

But only by beginning /now/ in the direction of making that version
declaration either mandatory, or at least strongly encouraged, do we
have a hope of having a significant-enough signal from it in several
years to come. If we don't start encouraging it, it won't be there at
all.

-- 
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk      |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/
0
leonerd
7/3/2020 6:06:21 PM
On Fri, 3 Jul 2020 at 19:38, Paul "LeoNerd" Evans
<leonerd@leonerd.org.uk> wrote:
>
> On Fri, 3 Jul 2020 19:22:03 +0200
> demerphq <demerphq@gmail.com> wrote:
>
> > We want to eventually ditch the perl 5 variant, and move to a saner
> > perl 7 or 8 variant, which means that ast some point we want the
> > parser to not know about 5 AT ALL, except when it throws exceptions.
> > Making the rule be "the parser starts out expecting perl 5" simply
> > does not make sense, for *any* version. Making the rule be "the parser
> > starts out expecting perl $Latest" does.
>
> Right now, we start off in "version 5" mode until we see a
> "use VERSION" which alters the idea. We should *strongly encourage*
> everyone to be explicit with their version statements. It is a shame
> more people haven't been using "use VERSION" so far, though that can be
> explained by the fact it isn't very powerful yet. Suggestions have been
> made that it should "use warnings" and so on - these could definitely
> help.
>
>
> How about this as an idea:
>
> At some point in the future, the semantics changes very slightly to:
> We start off in "guess probably version 5" mode, wherein any
> non-whitespace/comment syntax we see other than an explicit "use
> VERSION" statement provides a warning that the user didn't declare
> their version requirement. We'll continue presuming v5 for now unless
> they asked for something else, but that warning gives people a hint, a
> nudge that they should be explicit now.
>
> At some later point beyond that, it becomes a hard error. We can now
> delete all the old version-5 compat code in the core because we know
> (from the previous deprecation round and warnings) that everyone has
> been explicit on their version requirements.

I personally prefer the plan SawyerX has proposed, but I can live with
yours too.

cheers,
Yves


-- 
perl -Mre=debug -e "/just|another|perl|hacker/"
0
demerphq
7/3/2020 6:13:55 PM
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.
>
>
0
doomvox
7/3/2020 6:15:16 PM
On Fri, 3 Jul 2020 at 19:47, Paul "LeoNerd" Evans
<leonerd@leonerd.org.uk> wrote:
>
> On Fri, 3 Jul 2020 19:33:20 +0200
> demerphq <demerphq@gmail.com> wrote:
>
> > So if I understand you both correctly, we have to continue to support
> > all perl 5 code forever?
> >
> > Because that is what I understand you to be saying.
>
> Then you misunderstand. That is not at all what I am arguing.
>
> > To me this question comes down to a simple technical question: what
> > language variant does the parser start out expecting before it sees
> > the "use v7" line?
> >
> > If we say "perl 5" then we have to support all of perl 5 forever
> > don't we?
> >
> > Doesn't that kind of er, stand in the way of not supporting perl 5
> > forever?
>
> I'm saying that *right now* it should continue to behave like Perl 5,
> but after a suitable announcement period it should start giving
> "version is ambiguous" warnings. At some further point after that we
> can have it be an outright error for there not to be a version
> declaration, at which point we're free to cut off an older version of
> perl if we so wish.
>
> And by forcing everyone to have declared their version requirements by
> then we can do a simple grep for "use v5" across all of CPAN to gain a
> very easy simple metric on how much actual CPAN code is actually still
> using v5. When we feel that number is small enough - or the remaining
> outliers unimportant enough - we can cut it off.
>
> > Doesn't it make a lot more sense to say "prior to seeing a C<use
> > v$DIGIT;> statement the parser will be expecting the *latest* variant
> > of the language"? Isn't the certainty of that the only sane choice if
> > we are ever to deprecate older variant code?
>
> No. I'd say it makes more sense to say "prior to seeing a C<use
> v$DIGIT;> statement the parser will start off in ambiguous-guessing-5
> variant, which provokes a warning when it starts to parse real code".
> Isn't the certainty of knowing the author is now strongly encouraged to
> declare their version requirement the only sane choice if we are ever
> to deprecate older variant code while knowing it is safe to do so?

I dunno man, you seem to be just cheating the point here. How is
"ambiguous-guessing-5" mode compatible with us being on version 28 and
5 being dead for 8 years?

What you are actually saying is that "for now we will be in perl 5
mode, and  some time in the future we will start out in "seek a use
v$digit; statement mode, anything else will be an error".

I don't like that.

I want this:
---
package Whatever;
use v7;
---
to not be an error. I don't want to have to write:

---
use v7;
package Whatever;
---

I mean, what will this do to eval statements? Does every eval TEXT
have to be prefixed with a 'use v7' or whatever?

cheers,
Yves


-- 
perl -Mre=debug -e "/just|another|perl|hacker/"
0
demerphq
7/3/2020 6:20:04 PM
--------------EE3A9F72EF78CB85A919732A
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

I think this is a great solution. Certainly it's not sustainable to 
continue forever with:

use v7
use v8
use v9

As it's going to get crazy after a while.

As far as I know no other language requires you to *opt in *to latest 
version like this. Certainly not the languages I play in: C, C++, 
Python, PHP, Javascript.

I understand the use v7 thing because we have so much legacy code to 
support (for now). Over the course of the next X years/versions the 
amount of old and non-updated code will diminish and we could then 
assume the latest version unless we see a specificalyy use vX.

I support use v7 if the goal is to eventually get that legacy code 
(CPAN, etc) upgraded to support new features so that future versions of 
the interpreter can assume the current version and emit warnings or 
deprecations on old syntax/features.

I'm new to all of this so my vote means nothing, but I think this is a 
good goal. Use v7 for now, with the goal of "assuming current version" 
in the future when the code base catches up. The goal should be to make 
things easy for new developers. Right now there is a lot of tribal 
knowledge just to get started on "modern Perl".

- Scott

On 7/3/2020 10:47 AM, Paul "LeoNerd" Evans wrote:
> I'm saying that*right now*  it should continue to behave like Perl 5,
> but after a suitable announcement period it should start giving
> "version is ambiguous" warnings. At some further point after that we
> can have it be an outright error for there not to be a version
> declaration, at which point we're free to cut off an older version of
> perl if we so wish.
>
> And by forcing everyone to have declared their version requirements by
> then we can do a simple grep for "use v5" across all of CPAN to gain a
> very easy simple metric on how much actual CPAN code is actually still
> using v5. When we feel that number is small enough - or the remaining
> outliers unimportant enough - we can cut it off.

--------------EE3A9F72EF78CB85A919732A
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>I think this is a great solution. Certainly it's not sustainable
      to continue forever with:</p>
    use v7<br>
    use v8<br>
    use v9
    <p>As it's going to get crazy after a while. <br>
    </p>
    <p>As far as I know no other language requires you to <b>opt in </b>to
      latest version like this. Certainly not the languages I play in:
      C, C++, Python, PHP, Javascript. <br>
    </p>
    <p>I understand the use v7 thing because we have so much legacy code
      to support (for now). Over the course of the next X years/versions
      the amount of old and non-updated code will diminish and we could
      then assume the latest version unless we see a specificalyy use
      vX.</p>
    <p>I support use v7 if the goal is to eventually get that legacy
      code (CPAN, etc) upgraded to support new features so that future
      versions of the interpreter can assume the current version and
      emit warnings or deprecations on old syntax/features.</p>
    <p>I'm new to all of this so my vote means nothing, but I think this
      is a good goal. Use v7 for now, with the goal of "assuming current
      version" in the future when the code base catches up. The goal
      should be to make things easy for new developers. Right now there
      is a lot of tribal knowledge just to get started on "modern Perl".<br>
    </p>
    <p>- Scott<br>
    </p>
    <div class="moz-cite-prefix">On 7/3/2020 10:47 AM, Paul "LeoNerd"
      Evans wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:20200703184737.0d6fd56f@shy.leonerd.org.uk">
      <pre class="moz-quote-pre" wrap="">I'm saying that <b class="moz-txt-star"><span class="moz-txt-tag">*</span>right now<span class="moz-txt-tag">*</span></b> it should continue to behave like Perl 5,
but after a suitable announcement period it should start giving
"version is ambiguous" warnings. At some further point after that we
can have it be an outright error for there not to be a version
declaration, at which point we're free to cut off an older version of
perl if we so wish.

And by forcing everyone to have declared their version requirements by
then we can do a simple grep for "use v5" across all of CPAN to gain a
very easy simple metric on how much actual CPAN code is actually still
using v5. When we feel that number is small enough - or the remaining
outliers unimportant enough - we can cut it off.</pre>
    </blockquote>
  </body>
</html>

--------------EE3A9F72EF78CB85A919732A--
0
scott
7/3/2020 6:29:46 PM
On Fri, 3 Jul 2020 20:20:04 +0200
demerphq <demerphq@gmail.com> wrote:

> What you are actually saying is that "for now we will be in perl 5
> mode, and  some time in the future we will start out in "seek a use
> v$digit; statement mode, anything else will be an error".
> 
> I don't like that.
> 
> I want this:
> ---
> package Whatever;
> use v7;
> ---
> to not be an error. I don't want to have to write:
> 
> ---
> use v7;
> package Whatever;
> ---

OK that's fair. I guess it would probably be fine to accept "package"
before "use VERSION". There might be one or two other cases, but they
should be handled on a case-by-case basis. Maybe say no code with
runtime effects before a "use VERSION". I haven't fully thought this
one through yet I'll admit.

> I mean, what will this do to eval statements? Does every eval TEXT
> have to be prefixed with a 'use v7' or whatever?

Mmm... That's another exciting question I hadn't considered.

I think at this point there's sortof three separate containing
"contexts" in which we might find ourselves looking at some new perl
code in the parser, and wanting to have an idea of a version for it.

 * A newly loaded .pm file

 * The contents of a -e or -E commandline argument

 * A string given to eval()

While the idea of explicit "use VERSION" is attractive in the first
case, it doesn't really do much for the other two cases. Perhaps we may
have to have different rules for each case. I think already there's a
strong feeling that -e/-E arguments should remain in "no strict" mode,
because for little commandline one-liners nobody wants to have to "my"
everything. So already it's understandable that the rules might be
different in different places.

-- 
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk      |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/
0
leonerd
7/3/2020 6:30:06 PM
On Fri, 3 Jul 2020 11:29:46 -0700
Scott Baker <scott@perturb.org> wrote:

> As far as I know no other language requires you to *opt in *to latest 
> version like this. Certainly not the languages I play in: C, C++, 
> Python, PHP, Javascript.

I respectfully beg to differ, at least on the C front.

C compilers are well known to be notoriously conservative; you are
often stuck with C89 features unless you ask on the commandline to get
C99 or maybe if you are extremely lucky, you might be allowed C11.

And compilers differ on what the commandline flags might be - maybe
it's -std=c99 for gcc; but that might not be the case for all the weird
UNIX ones. It's a total mess.

As an often-C programmer I would dearly love to have the "use VERSION"
mechanism in C as well. How wonderful I would find it to be able to

  use C11;

at the top of my .c files, and know that any C compiler will understand
what I mean.

Perl has a great mechanism in "use VERSION" - I don't want to see it go
to waste.

-- 
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk      |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/
0
leonerd
7/3/2020 6:33:15 PM
On 7/3/20 8:06 PM, Craig A. Berry wrote:
> On Fri, Jul 3, 2020 at 8:42 AM Sawyer X <xsawyerx@gmail.com> wrote:
>>
>> On 6/30/20 5:50 AM, Craig A. Berry wrote:
>>> On Mon, Jun 29, 2020 at 3:54 PM Kent Fredric <kentfredric@gmail.com> wrote:
>>>
>>>> the net result, whatever p5p does
>>> For the record, p5p has nothing to do with it.  The public mailing
>>> list appears to have been carefully and intentionally excluded from
>>> the first few months of Perl 7 development,
>>
>>
>> I understand how this seems, but I want to try and explain this:
> Thanks for the reply.  I think I already understand how you see the
> mailing list.
>
>> * p5p has a record of being a very unfruitful place for in-depth public
>> discussion which is not laser focused.
> ...
>> * Since the proposal is too large for p5p to properly evaluate - this
>> thread is strong evidence of it - we had discussed it within that group.
> ...
>> Now, I understand this seems like a no-starter and many think that any
>> such plan should go to p5p, but I disagree. p5p is not the developers
>> mailing list as it intends to be. In practice, it is a mailing list for
>> those interested in the development, which the developers are part of.
> ...
>> In short, it's difficult to engage in the way that the list - or some
>> people on the list - would like people to engage in. I do apologize I am
>> not able to keep up. I wish I could.
> However difficult it is to engage the mailing list (and I've been an
> observer of at least some of those difficulties for a couple of
> decades), it's never been considered optional.  This is partly
> convention and tradition, but not just of the "we've always done it
> this way" type but more because there's never been an equally
> efficient (if messy) mechanism for providing transparency and keeping
> the "open" in open source. My reading of L<perlpolicy/GOVERNANCE> is
> that making major changes to Perl actually requires consulting p5p
> (what Larry calls the legislative branch).


I think our interpretation of "p5p" is different. Despite how it might 
seem to some people (not you necessarily), I don't make almost *any* 
decision by myself. There are myriad of reasons - I don't have as much 
experience as many others, I don't have as much expertise as many 
others. Decisions I make are always done as part of a group. We don't 
always have a consensus, but I always make it within as large a group as 
I can - emphasis on *can*.


This decision was done with the core of effective contributors to the 
language who attend the summit and with numerous stakeholders. I do 
consider this having been done *with* p5p - not just "consulting," 
rather than by myself. It just wasn't done with the "p5p mailing list" 
which includes many who are not developers of the language or 
stakeholders in it.


I understand this upsets many. Some we should've reached out to 
(yourself included) and some who assume *everyone* (or at least everyone 
on this list) have the same say in what decisions will be made. For 
those that should've been also consulted (even for a +1 on their end), I 
do apologize. For those who believe *everyone* should've been consulted, 
I direct them to the history of "p5p" and its capability at making such 
design decisions done in the great vast space of this mailing list. We 
just couldn't do it this way.
0
xsawyerx
7/3/2020 6:34:45 PM

> On Jul 3, 2020, at 1:30 PM, Paul LeoNerd Evans =
<leonerd@leonerd.org.uk> wrote:
>=20
> On Fri, 3 Jul 2020 20:20:04 +0200
> demerphq <demerphq@gmail.com> wrote:
>=20
>> I mean, what will this do to eval statements? Does every eval TEXT
>> have to be prefixed with a 'use v7' or whatever?
>=20
> Mmm... That's another exciting question I hadn't considered.
>=20
> * The contents of a -e or -E commandline argument

I think that does need to be discussed. It may be that -e needs to be v5 =
and deprecated in 7 in favor of -E which uses the v equal to the version =
of perl that invoked it.


> * A string given to eval()
>=20

I don't see the problem. $^H inherits from the scope it comes out of =
right? so eval should follow the same rules as the line it was invoked =
from unless it changes them, right?
0
toddr
7/3/2020 7:00:39 PM
--Apple-Mail=_A461CED3-A8BA-40AC-A441-0EC142F51428
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On Jul 3, 2020, at 12:06 PM, Craig A. Berry <craig.a.berry@gmail.com> =
wrote:
>=20
> On Fri, Jul 3, 2020 at 8:42 AM Sawyer X <xsawyerx@gmail.com> wrote:
>>=20
>>=20
>> On 6/30/20 5:50 AM, Craig A. Berry wrote:
>>> On Mon, Jun 29, 2020 at 3:54 PM Kent Fredric <kentfredric@gmail.com> =
wrote:
>>>=20
>>>> the net result, whatever p5p does
>>> For the record, p5p has nothing to do with it.  The public mailing
>>> list appears to have been carefully and intentionally excluded from
>>> the first few months of Perl 7 development,
>>=20
>>=20
>>=20
>> I understand how this seems, but I want to try and explain this:
>=20
> Thanks for the reply.  I think I already understand how you see the
> mailing list.
>=20
>> * p5p has a record of being a very unfruitful place for in-depth =
public
>> discussion which is not laser focused.
> ...
>> * Since the proposal is too large for p5p to properly evaluate - this
>> thread is strong evidence of it - we had discussed it within that =
group.
> ...
>> Now, I understand this seems like a no-starter and many think that =
any
>> such plan should go to p5p, but I disagree. p5p is not the developers
>> mailing list as it intends to be. In practice, it is a mailing list =
for
>> those interested in the development, which the developers are part =
of.
> ...
>> In short, it's difficult to engage in the way that the list - or some
>> people on the list - would like people to engage in. I do apologize I =
am
>> not able to keep up. I wish I could.
>=20
> However difficult it is to engage the mailing list (and I've been an
> observer of at least some of those difficulties for a couple of
> decades), it's never been considered optional.  This is partly
> convention and tradition, but not just of the "we've always done it
> this way" type but more because there's never been an equally
> efficient (if messy) mechanism for providing transparency and keeping
> the "open" in open source. My reading of L<perlpolicy/GOVERNANCE> is
> that making major changes to Perl actually requires consulting p5p
> (what Larry calls the legislative branch).

=46rom what I can intuit from Larry's SOTO 20 years ago, Perl 6 was not =
initially planned on the p5p mailing list either.

https://youtu.be/a1SEt_-QMDo?t=3D3014 =
<https://youtu.be/a1SEt_-QMDo?t=3D3014>

https://www.perl.com/pub/2000/10/23/soto2000.html/ =
<https://www.perl.com/pub/2000/10/23/soto2000.html/>

The most amusing part of the talk for me is when Larry said: "We intend =
to abandon the Perl 5 porter=E2=80=99s model of development, which =
demonstrably leads to a lot of talk but little action."

Todd


--Apple-Mail=_A461CED3-A8BA-40AC-A441-0EC142F51428
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;" class=3D""><div =
dir=3D"auto" style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
line-break: after-white-space;" class=3D""><br class=3D""><div><br =
class=3D""><blockquote type=3D"cite" class=3D""><div class=3D"">On Jul =
3, 2020, at 12:06 PM, Craig A. Berry &lt;<a =
href=3D"mailto:craig.a.berry@gmail.com" =
class=3D"">craig.a.berry@gmail.com</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div class=3D"">On =
Fri, Jul 3, 2020 at 8:42 AM Sawyer X &lt;<a =
href=3D"mailto:xsawyerx@gmail.com" class=3D"">xsawyerx@gmail.com</a>&gt; =
wrote:<br class=3D""><blockquote type=3D"cite" class=3D""><br =
class=3D""><br class=3D"">On 6/30/20 5:50 AM, Craig A. Berry wrote:<br =
class=3D""><blockquote type=3D"cite" class=3D"">On Mon, Jun 29, 2020 at =
3:54 PM Kent Fredric &lt;<a href=3D"mailto:kentfredric@gmail.com" =
class=3D"">kentfredric@gmail.com</a>&gt; wrote:<br class=3D""><br =
class=3D""><blockquote type=3D"cite" class=3D"">the net result, whatever =
p5p does<br class=3D""></blockquote>For the record, p5p has nothing to =
do with it. &nbsp;The public mailing<br class=3D"">list appears to have =
been carefully and intentionally excluded from<br class=3D"">the first =
few months of Perl 7 development,<br class=3D""></blockquote><br =
class=3D""><br class=3D""><br class=3D"">I understand how this seems, =
but I want to try and explain this:<br class=3D""></blockquote><br =
class=3D"">Thanks for the reply. &nbsp;I think I already understand how =
you see the<br class=3D"">mailing list.<br class=3D""><br =
class=3D""><blockquote type=3D"cite" class=3D"">* p5p has a record of =
being a very unfruitful place for in-depth public<br class=3D"">discussion=
 which is not laser focused.<br class=3D""></blockquote>...<br =
class=3D""><blockquote type=3D"cite" class=3D"">* Since the proposal is =
too large for p5p to properly evaluate - this<br class=3D"">thread is =
strong evidence of it - we had discussed it within that group.<br =
class=3D""></blockquote>...<br class=3D""><blockquote type=3D"cite" =
class=3D"">Now, I understand this seems like a no-starter and many think =
that any<br class=3D"">such plan should go to p5p, but I disagree. p5p =
is not the developers<br class=3D"">mailing list as it intends to be. In =
practice, it is a mailing list for<br class=3D"">those interested in the =
development, which the developers are part of.<br =
class=3D""></blockquote>...<br class=3D""><blockquote type=3D"cite" =
class=3D"">In short, it's difficult to engage in the way that the list - =
or some<br class=3D"">people on the list - would like people to engage =
in. I do apologize I am<br class=3D"">not able to keep up. I wish I =
could.<br class=3D""></blockquote><br class=3D"">However difficult it is =
to engage the mailing list (and I've been an<br class=3D"">observer of =
at least some of those difficulties for a couple of<br =
class=3D"">decades), it's never been considered optional. &nbsp;This is =
partly<br class=3D"">convention and tradition, but not just of the =
"we've always done it<br class=3D"">this way" type but more because =
there's never been an equally<br class=3D"">efficient (if messy) =
mechanism for providing transparency and keeping<br class=3D"">the =
"open" in open source. My reading of L&lt;perlpolicy/GOVERNANCE&gt; =
is<br class=3D"">that making major changes to Perl actually requires =
consulting p5p<br class=3D"">(what Larry calls the legislative =
branch).<br class=3D""></div></div></blockquote></div><br class=3D""><div =
class=3D"">=46rom what I can intuit from Larry's SOTO 20 years ago, Perl =
6 was not initially planned on the p5p mailing list either.</div><div =
class=3D""><br class=3D""></div><div class=3D""><a =
href=3D"https://youtu.be/a1SEt_-QMDo?t=3D3014" =
class=3D"">https://youtu.be/a1SEt_-QMDo?t=3D3014</a></div><div =
class=3D""><br class=3D""></div><div class=3D""><a =
href=3D"https://www.perl.com/pub/2000/10/23/soto2000.html/" =
class=3D"">https://www.perl.com/pub/2000/10/23/soto2000.html/</a></div><di=
v class=3D""><br class=3D""></div><div class=3D"">The most amusing part =
of the talk for me is when Larry said: "We intend to abandon the Perl 5 =
porter=E2=80=99s model of development, which demonstrably leads to =
a&nbsp;lot of talk but little action."</div><div class=3D""><br =
class=3D""></div><div class=3D"">Todd</div><div class=3D""><br =
class=3D""></div></div></body></html>=

--Apple-Mail=_A461CED3-A8BA-40AC-A441-0EC142F51428--
0
toddr
7/3/2020 7:19:24 PM
On Sat, 4 Jul 2020 at 06:29, Scott Baker <scott@perturb.org> wrote:

> As far as I know no other language requires you to opt in to latest version like this. Certainly not the languages I play in: C, C++, Python, PHP, Javascript.

Of these, neither PHP or JavaScript are extensively deployed for
"system level tasks", and so the risk of breakinging things outside
somebody's webapp are small.

C and C++ both have the benefit of a compile time isolation, which
means if you upgrade your compiler, even though your code may have
incompatibilities with the newer compiler, your existing applications
don't spontaneously break due to the upgrade.

But Perl is used for the same sort of tasks C is used for in systems,
but doesn't have the luxury of being able to avoid breakage when your
language updates.

Rust, for comparison, does have some version system where your build
chain states the edition of rust it targets, and that declaration lies
in either a config file (which is then later passed to rustc), or in a
manual invocation of rustc.

But you simply can't do that with perl, because you need to retain the
information *after* you deploy it to the target system, and it gets
re-evaulated *every* run.

So to be fair, the only thing on that list that is comparable to Perl,
in all of "scale", "usecases", and "problems with not having a compile
stage", is Python.

And the Python 2 -> Python 3 situation, as a vendor, can only be
described as "a tragedy".

Right now, quite literally hundreds of python2 packages/programs are
getting somewhat unceremoniously nuked, and users will never be able
to use them again, as a result  of their failure to adopt python3 (
due to upstream dying ).



-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL
0
kentfredric
7/3/2020 7:20:29 PM
On Fri, 3 Jul 2020 14:00:39 -0500
Todd Rinaldo <toddr@cpanel.net> wrote:

> > On Jul 3, 2020, at 1:30 PM, Paul LeoNerd Evans
> > <leonerd@leonerd.org.uk> wrote:
> > 
> > Mmm... That's another exciting question I hadn't considered.
> > 
> > * The contents of a -e or -E commandline argument  
> 
> I think that does need to be discussed. It may be that -e needs to be
> v5 and deprecated in 7 in favor of -E which uses the v equal to the
> version of perl that invoked it.

Commandline is quite an interesting case, but there's two parts to it:

 * Developers/users running "perl" on their $PATH

 * Existing system scripts/etc.. that want to invoke /usr/bin/perl on
   some small fragment

I think in the former case the user has chosen their perl by $PATH,
whereas system scripts are going to be quite different. It may be that
we'd have to tie the choice onto a binary name - /usr/bin/perl5 vs
perl7 or something else of that nature.

At very worst, there's always a -5 or -7 flag; I note they're currently
free:

  $ perl -7
  Unrecognized switch: -7  (-h will show valid options).

> > * A string given to eval()
> 
> I don't see the problem. $^H inherits from the scope it comes out of
> right? so eval should follow the same rules as the line it was
> invoked from unless it changes them, right?

Yes; the more I think about it you're right there. An eval() has always
inherited the feature pragmata from its surrounding environment, so
that can just continue to happen exactly as before.

-- 
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk      |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/
0
leonerd
7/3/2020 7:34:11 PM
On Fri, Jul 3, 2020 at 2:19 PM Todd Rinaldo <toddr@cpanel.net> wrote:
>
>
>
> On Jul 3, 2020, at 12:06 PM, Craig A. Berry <craig.a.berry@gmail.com> wro=
te:

> However difficult it is to engage the mailing list (and I've been an
> observer of at least some of those difficulties for a couple of
> decades), it's never been considered optional.  This is partly
> convention and tradition, but not just of the "we've always done it
> this way" type but more because there's never been an equally
> efficient (if messy) mechanism for providing transparency and keeping
> the "open" in open source. My reading of L<perlpolicy/GOVERNANCE> is
> that making major changes to Perl actually requires consulting p5p
> (what Larry calls the legislative branch).
>
>
> From what I can intuit from Larry's SOTO 20 years ago, Perl 6 was not ini=
tially planned on the p5p mailing list either.
>
> https://youtu.be/a1SEt_-QMDo?t=3D3014
>
> https://www.perl.com/pub/2000/10/23/soto2000.html/
>
> The most amusing part of the talk for me is when Larry said: "We intend t=
o abandon the Perl 5 porter=E2=80=99s model of development, which demonstra=
bly leads to a lot of talk but little action."

First of all, only Larry gets to do this; secondly, there was a lot of
documentation and public discussion about what the plan was even if it
moved to different mailings lists; and thirdly, if you're using Perl 6
as a model for how to manage a big transition, well, yikes.
0
craig
7/3/2020 8:09:41 PM
--5f44ef6cd56a4980898637f23da673aa
Content-Type: text/plain

On Fri, Jul 3, 2020, at 1:00 PM, Kent Fredric wrote:
> [top posted]
> 
> Can you be more brief in future? This is a lot of content, and a
> shortage of actual information. It's a waste of my time and a headache
> to read this shit.

Kent, your message, quoted above is not acceptable. Your words are certainly not kind, and they do not even meet the low standard of "civility" required by perlpolicy <https://perldoc.perl.org/5.32.0/perlpolicy.html#STANDARDS-OF-CONDUCT>. 

This email to you message constitutes a formal warning under that policy.

I understand that there's a lot going on with perl5-porters right now, and a large volume of discussion, and everybody (including me) is having a lot of feelings about it, but none of this gives you license to say that anyone else on the list is waiting your time or, especially, that their work is shit.

-- 
rjbs
--5f44ef6cd56a4980898637f23da673aa
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}</style></head><body><div>On Fri, Jul 3, =
2020, at 1:00 PM, Kent Fredric wrote:<br></div><blockquote type=3D"cite"=
 id=3D"qt" style=3D""><div>[top posted]<br></div><div><br></div><div>Can=
 you be more brief in future? This is a lot of content, and a<br></div><=
div>shortage of actual information. It's a waste of my time and a headac=
he<br></div><div>to read this shit.<br></div></blockquote><div><br></div=
><div>Kent, your message, quoted above is not acceptable.&nbsp; Your wor=
ds are certainly not kind, and they do not even meet the low standard of=
 "civility" required by <a href=3D"https://perldoc.perl.org/5.32.0/perlp=
olicy.html#STANDARDS-OF-CONDUCT">perlpolicy</a>.&nbsp; <br></div><div><b=
r></div><div>This email to you message constitutes a formal warning unde=
r that policy.<br></div><div><br></div><div>I understand that there's a =
lot going on with perl5-porters right now, and a large volume of discuss=
ion, and everybody (including me) is having a lot of feelings about it, =
but none of this gives you license to say that anyone else on the list i=
s waiting your time or, especially, that their work is shit.<br></div><d=
iv><br></div><div>--&nbsp;<br></div><div>rjbs</div></body></html>
--5f44ef6cd56a4980898637f23da673aa--
0
perl
7/3/2020 8:15:04 PM
On Fri, 3 Jul 2020 20:20:04 +0200
demerphq <demerphq@gmail.com> wrote:

> I want this:
> ---
> package Whatever;
> use v7;
> ---
> to not be an error. I don't want to have to write:
> 
> ---
> use v7;
> package Whatever;
> ---

Not that it matters much to the argument, but I have just found a very
minor reason to want to `use VERSION` even before your package
statement.

Perl 5.12 added the "package NAME VERSION;" syntax, meaning you can
write

  package Whatever 1.23;

instead of the more longwinded

  package Whatever;
  our $VERSION = 1.23;

Perl older than 5.12 will get upset:

  $ perl5.10.1 Whatever.pm
  syntax error at Whatever.pm line 1, near "package Whatever 1.23"
  Execution of Whatever.pm aborted due to compilation errors.

Not a huge problem, but if you write

  use v5.12;
  package Whatever 1.23;

then at least you get a prettier error message that doesn't confuse
users so much:

  $ perl5.10.1 Whatever.pm
  Perl v5.12.0 required--this is only v5.10.1, stopped at Whatever.pm line 1.

-- 
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk      |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/
0
leonerd
7/3/2020 11:28:41 PM
On 2020-07-03 10:47 a.m., demerphq wrote:
> ---
> package Foo; # parsed as v-latest but it doesn't matter.
> use v7; # give me well defined semantics
> use strict; # no op
> ---

Personally I never understood why so many people write their file scope pragmas 
or non-symbol-installing package declarations within the current file's class 
declaration rather than before it.

To me, this always seemed the best order for things:

<file start>
#optional shebang line
use vN;
use other pragmas;
use other non-imported modules;
package MyPackage;
use symbol-importing modules;
<rest of the code>

This also means that the "use v" statement is always the first thing in the 
file, before EVERYTHING else, and sets a context for the rest.

-- Darren Duncan
0
darren
7/4/2020 1:13:56 AM
--00000000000012124405a99534d2
Content-Type: text/plain; charset="UTF-8"

On Fri, 3 Jul 2020 at 20:30, Scott Baker <scott@perturb.org> wrote:

> I think this is a great solution. Certainly it's not sustainable to
> continue forever with:
> use v7
> use v8
> use v9
>
> As it's going to get crazy after a while.
>

In-source language version (or protocol version) is the greatest feature of
perl. It allows you to handle eventual consistency problems.
In languages you mentioned you can use only one version of language
specification - one which is supported by your tooling.

That  will become quite an issue once you have a large code base. It may
force you to maintain code you already deprecated.

On other hand it can be easily handled automatically by scriptable
refactoring tools (PPI, Babble, Code::ART, whatever comes in future)
along with CI tools. And ability to specify future version of protocol just
to disable usage of constructs that will be deprecated in a short future?
IMHO Invaluable.

As far as I know no other language requires you to *opt in *to latest
> version like this. Certainly not the languages I play in: C, C++, Python,
> PHP, Javascript.
>
> I understand the use v7 thing because we have so much legacy code to
> support (for now). Over the course of the next X years/versions the amount
> of old and non-updated code will diminish and we could then assume the
> latest version unless we see a specificalyy use vX.
>
> I support use v7 if the goal is to eventually get that legacy code (CPAN,
> etc) upgraded to support new features so that future versions of the
> interpreter can assume the current version and emit warnings or
> deprecations on old syntax/features.
>
> I'm new to all of this so my vote means nothing, but I think this is a
> good goal. Use v7 for now, with the goal of "assuming current version" in
> the future when the code base catches up. The goal should be to make things
> easy for new developers. Right now there is a lot of tribal knowledge just
> to get started on "modern Perl".
>
> - Scott
> On 7/3/2020 10:47 AM, Paul "LeoNerd" Evans wrote:
>
> I'm saying that **right now** it should continue to behave like Perl 5,
> but after a suitable announcement period it should start giving
> "version is ambiguous" warnings. At some further point after that we
> can have it be an outright error for there not to be a version
> declaration, at which point we're free to cut off an older version of
> perl if we so wish.
>
> And by forcing everyone to have declared their version requirements by
> then we can do a simple grep for "use v5" across all of CPAN to gain a
> very easy simple metric on how much actual CPAN code is actually still
> using v5. When we feel that number is small enough - or the remaining
> outliers unimportant enough - we can cut it off.
>
>

--00000000000012124405a99534d2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Fri, 3 Jul 2020 at 20:30, Scott Ba=
ker &lt;<a href=3D"mailto:scott@perturb.org">scott@perturb.org</a>&gt; wrot=
e:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
 =20
   =20
 =20
  <div>
    <p>I think this is a great solution. Certainly it&#39;s not sustainable
      to continue forever with:</p>
    use v7<br>
    use v8<br>
    use v9
    <p>As it&#39;s going to get crazy after a while. <br></p></div></blockq=
uote><div><br></div><div>In-source language version (or protocol version) i=
s the greatest feature of perl. It allows you to handle eventual consistenc=
y problems.</div><div>In languages you mentioned you can use only one versi=
on of language specification - one which is supported by your tooling.</div=
><div><br></div><div>That=C2=A0 will become quite an issue once you have a =
large code base. It may force you to maintain code you already deprecated.<=
/div><div><br></div><div>On other hand it can be easily handled automatical=
ly by scriptable refactoring tools (PPI, Babble, Code::ART, whatever comes =
in future)</div><div>along with CI tools. And ability to specify future ver=
sion of protocol just to disable usage of constructs that will be deprecate=
d in a short future?</div><div>IMHO Invaluable.<br></div><div><br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t:1px solid rgb(204,204,204);padding-left:1ex"><div><p>
    </p>
    <p>As far as I know no other language requires you to <b>opt in </b>to
      latest version like this. Certainly not the languages I play in:
      C, C++, Python, PHP, Javascript. <br>
    </p>
    <p>I understand the use v7 thing because we have so much legacy code
      to support (for now). Over the course of the next X years/versions
      the amount of old and non-updated code will diminish and we could
      then assume the latest version unless we see a specificalyy use
      vX.</p>
    <p>I support use v7 if the goal is to eventually get that legacy
      code (CPAN, etc) upgraded to support new features so that future
      versions of the interpreter can assume the current version and
      emit warnings or deprecations on old syntax/features.</p>
    <p>I&#39;m new to all of this so my vote means nothing, but I think thi=
s
      is a good goal. Use v7 for now, with the goal of &quot;assuming curre=
nt
      version&quot; in the future when the code base catches up. The goal
      should be to make things easy for new developers. Right now there
      is a lot of tribal knowledge just to get started on &quot;modern Perl=
&quot;.<br>
    </p>
    <p>- Scott<br>
    </p>
    <div>On 7/3/2020 10:47 AM, Paul &quot;LeoNerd&quot;
      Evans wrote:<br>
    </div>
    <blockquote type=3D"cite">
      <pre>I&#39;m saying that <b><span>*</span>right now<span>*</span></b>=
 it should continue to behave like Perl 5,
but after a suitable announcement period it should start giving
&quot;version is ambiguous&quot; warnings. At some further point after that=
 we
can have it be an outright error for there not to be a version
declaration, at which point we&#39;re free to cut off an older version of
perl if we so wish.

And by forcing everyone to have declared their version requirements by
then we can do a simple grep for &quot;use v5&quot; across all of CPAN to g=
ain a
very easy simple metric on how much actual CPAN code is actually still
using v5. When we feel that number is small enough - or the remaining
outliers unimportant enough - we can cut it off.</pre>
    </blockquote>
  </div>

</blockquote></div></div>

--00000000000012124405a99534d2--
0
happy
7/4/2020 3:26:01 AM
--000000000000e0cb3705a9961291
Content-Type: text/plain; charset="UTF-8"

On Fri, Jul 3, 2020 at 6:14 PM Darren Duncan <darren@darrenduncan.net>
wrote:

> Personally I never understood why so many people write their file scope
> pragmas
> or non-symbol-installing package declarations within the current file's
> class
> declaration rather than before it.
>

I do:

    use strict;
    use warnings;
    package Foo;

...because I have tooling that inserts an 'our $VERSION = ...' declaration
into packages that are missing them, in the line immediately following the
package declaration, and perlcritic tends to complain if there is any code
that precedes a 'use strict'. It seems fairly natural to me to do it this
way, and it seems quite logical to place a 'use vX' declaration as early on
in the file as possible, as it would affect the parsing of that file (just
as 'use utf8' does).

--000000000000e0cb3705a9961291
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon=
t-size:small"></div></div><div class=3D"gmail_quote"><div dir=3D"ltr" class=
=3D"gmail_attr">On Fri, Jul 3, 2020 at 6:14 PM Darren Duncan &lt;<a href=3D=
"mailto:darren@darrenduncan.net">darren@darrenduncan.net</a>&gt; wrote:<br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex">
Personally I never understood why so many people write their file scope pra=
gmas <br>
or non-symbol-installing package declarations within the current file&#39;s=
 class <br>
declaration rather than before it.<br></blockquote><div><br></div><div><div=
 style=3D"font-size:small" class=3D"gmail_default">I do:</div><div style=3D=
"font-size:small" class=3D"gmail_default"><br></div><div style=3D"font-size=
:small" class=3D"gmail_default">=C2=A0=C2=A0=C2=A0 use strict;</div><div st=
yle=3D"font-size:small" class=3D"gmail_default">=C2=A0=C2=A0=C2=A0 use warn=
ings;</div><div style=3D"font-size:small" class=3D"gmail_default">=C2=A0=C2=
=A0=C2=A0 package Foo;</div><div style=3D"font-size:small" class=3D"gmail_d=
efault"><br></div><div style=3D"font-size:small" class=3D"gmail_default">..=
because I have tooling that inserts an &#39;our $VERSION =3D ...&#39; decla=
ration into packages that are missing them, in the line immediately followi=
ng the package declaration, and perlcritic tends to complain if there is an=
y code that precedes a &#39;use strict&#39;. It seems fairly natural to me =
to do it this way, and it seems quite logical to place a &#39;use vX&#39; d=
eclaration as early on in the file as possible, as it would affect the pars=
ing of that file (just as &#39;use utf8&#39; does).</div><div style=3D"font=
-size:small" class=3D"gmail_default"><br></div><div style=3D"font-size:smal=
l" class=3D"gmail_default"></div><br></div><div>=C2=A0</div></div></div>

--000000000000e0cb3705a9961291--
0
perl
7/4/2020 4:28:14 AM
--00000000000063c8cf05a9963566
Content-Type: text/plain; charset="UTF-8"

Sawyer said:

> This decision was done with the core of effective contributors to the
> language who attend the summit and with numerous stakeholders. I do
> consider this having been done *with* p5p - not just "consulting,"
> rather than by myself. It just wasn't done with the "p5p mailing list"
> which includes many who are not developers of the language or
> stakeholders in it.

> ...

> I will reach out to the group to get their explicit permission to publicly
> share who is in this group. I will note this group includes people who
> are frequent contributors (such as Dave Mitchell, Tony Cook, Karl
> Williamson, Jim Keenan, Todd Rinaldo, etc.), people from toolchain
> (Karen Etheridge, Leon Timmermans - who fits the previous group as
> well), and representatives of other vendors (primarily Debian).

To clarify:
I was not invited to the p5h meet last year; I was not involved in any Zoom
sessions with you, nor included in any email discussions. I saw the google
document you circulated, but did not know the names of the other
participants;
I left a few comments in the document, including one very specifically about
the schedule, which garnered zero responses.  I was certainly not aware of
any
specific action that was intended to be taken on a particular date, and the
specifics of the announcement at CiC came as a surprise to me.  Nothing I
said
should have been interpreted as broad support for a plan that I was aware of
only in the phrasing of "A Plan for Perl" (note: NOT the same as "THE Plan
for
Perl").

I wonder how many other people in the list you consider "the decision having
been done with" have had their positionsmisunderstood or misrepresented by
you. It's a shame, because if we had all been able to communicate more
clearly and sooner, we might not be in such a situation now.

--00000000000063c8cf05a9963566
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Sawyer said:<br><br>&gt; This decision was done with the c=
ore of effective contributors to the<br>&gt; language who attend the summit=
 and with numerous stakeholders. I do<br>&gt; consider this having been don=
e *with* p5p - not just &quot;consulting,&quot;<br>&gt; rather than by myse=
lf. It just wasn&#39;t done with the &quot;p5p mailing list&quot;<br>&gt; w=
hich includes many who are not developers of the language or<br>&gt; stakeh=
olders in it.<br><br>&gt; ...<br><br>&gt; I will reach out to the group to =
get their explicit permission to publicly<br>&gt; share who is in this grou=
p. I will note this group includes people who<br>&gt; are frequent contribu=
tors (such as Dave Mitchell, Tony Cook, Karl<br>&gt; Williamson, Jim Keenan=
, Todd Rinaldo, etc.), people from toolchain<br>&gt; (Karen Etheridge, Leon=
 Timmermans - who fits the previous group as<br>&gt; well), and representat=
ives of other vendors (primarily Debian).<br><br><div style=3D"font-size:sm=
all" class=3D"gmail_default">To clarify:</div>I was not invited to the p5h =
meet last year; I was not involved in any Zoom<br>sessions with you, nor in=
cluded in any email discussions. I saw the google<br>document you circulate=
d, but did not know the names of the other participants;<br>I left a few co=
mments in the document, including one very specifically about<br>the schedu=
le, which garnered zero responses.=C2=A0 I was certainly not aware of any<b=
r>specific action that was intended to be taken on a particular date, and t=
he<br>specifics of the announcement at CiC came as a surprise to me.=C2=A0 =
Nothing I said<br>should have been interpreted as broad support for a plan =
that I was aware of<br>only in the phrasing of &quot;A Plan for Perl&quot; =
(note: NOT the same as &quot;THE Plan for<br>Perl&quot;).<span class=3D"gma=
il_default" style=3D"font-size:small"></span><br><br>I wonder how many othe=
r people in=C2=A0the list you consider &quot;the decision having<br>been do=
ne with&quot; have had their positionsmisunderstood or misrepresented by<br=
>you. It&#39;s a shame, because if we had all been able to communicate more=
<br>clearly and sooner, we might not be in such a situation now.<br><br></d=
iv>

--00000000000063c8cf05a9963566--
0
perl
7/4/2020 4:37:53 AM
On 7/4/20 7:37 AM, Karen Etheridge wrote:
> Sawyer said:
>
> > This decision was done with the core of effective contributors to the
> > language who attend the summit and with numerous stakeholders. I do
> > consider this having been done *with* p5p - not just "consulting,"
> > rather than by myself. It just wasn't done with the "p5p mailing list"
> > which includes many who are not developers of the language or
> > stakeholders in it.
>
> > ...
>
> > I will reach out to the group to get their explicit permission to 
> publicly
> > share who is in this group. I will note this group includes people who
> > are frequent contributors (such as Dave Mitchell, Tony Cook, Karl
> > Williamson, Jim Keenan, Todd Rinaldo, etc.), people from toolchain
> > (Karen Etheridge, Leon Timmermans - who fits the previous group as
> > well), and representatives of other vendors (primarily Debian).
>
> To clarify:
> I was not invited to the p5h meet last year; I was not involved in any 
> Zoom
> sessions with you, nor included in any email discussions. I saw the google
> document you circulated, but did not know the names of the other 
> participants;
> I left a few comments in the document, including one very specifically 
> about
> the schedule, which garnered zero responses.  I was certainly not 
> aware of any
> specific action that was intended to be taken on a particular date, 
> and the
> specifics of the announcement at CiC came as a surprise to me. Nothing 
> I said
> should have been interpreted as broad support for a plan that I was 
> aware of
> only in the phrasing of "A Plan for Perl" (note: NOT the same as "THE 
> Plan for
> Perl").


I apologize that the names on the document were not public. I thought 
they were - this was an oversight, not an intentional situation. Since 
the original threads were open in the "to" and I requested feedback and 
to generate conversations - as well as conducted numerous one-on-one 
communications (whether by mail, IRC, or video/conference) - I had 
wrongly assumed the names on the document were open. I don't recall 
anyone reaching out to me and saying otherwise. If they did, this was 
also an oversight, I assure you.


> I wonder how many other people in the list you consider "the decision 
> having
> been done with" have had their positionsmisunderstood or misrepresented by
> you.


This is always possible and I wouldn't be surprised. However, I do want 
to clarify that we don't work with a consensus. Some decisions are made 
without everyone's consent and some decisions that I approve, I am also 
unhappy with. We try to work together and eventually come to a decision, 
even if not everyone agrees. We simply cannot make *everyone* happy 
because some of us have conflicting interests.


There is no perfect solution, which I feel some people seem to be 
demanding. Sorry, I do wish it were done better. It wasn't perfect, I 
know, but we definitely have put a *lot* of effort and discussed this 
for a fairly long time. While we could have fixed a few things along the 
way, I can't see how it could have been considerably better, only slightly.


> It's a shame, because if we had all been able to communicate more
> clearly and sooner, we might not be in such a situation now.


It's a shame, but I think it's wishful thinking to assume it could have 
been considerably better if only $x were to happen. There's a bias here 
where we assume that we see is all there is. "Clearly you could have 
responded to that comment" or "Clearly we have just spoken to that 
person - nothing would have been simpler and it could all have been 
done," without knowing what was done and how much effort there was. It 
doesn't help assuage the frustration some people have, but it is true 
nonetheless. Again, I'm sorry it wasn't better.


Not that we're on the list, we can try to make this better together.
0
xsawyerx
7/4/2020 9:54:16 AM
On Fri, 3 Jul 2020 21:28:14 -0700
Karen Etheridge <perl@froods.org> wrote:

> On Fri, Jul 3, 2020 at 6:14 PM Darren Duncan <darren@darrenduncan.net>
> wrote:
> 
> > Personally I never understood why so many people write their file
> > scope pragmas
> > or non-symbol-installing package declarations within the current
> > file's class
> > declaration rather than before it.
> >  
> 
> I do:
> 
>     use strict;
>     use warnings;
>     package Foo;

I always used to

  package Thingy;

  use strict;
  use warnings;
  ...

But lately, the more I write using Object::Pad (which needs to appear
-before- the class statement), I've taken to writing

  use v5.26;  # signatures
  use Object::Pad 0.19;

  class My::Class::Here;
  ...

-- 
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk      |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/
0
leonerd
7/4/2020 10:58:16 AM
On Sat, 04 Jul 2020 11:54:16 +0200, Sawyer X <xsawyerx@gmail.com> wrote:

>
> On 7/4/20 7:37 AM, Karen Etheridge wrote:
>> Sawyer said:
>>
>> > This decision was done with [...] this group includes [...] Karen Etheridge
>>
>> I was certainly not aware of any
>> specific action that was intended to be taken on a particular date, and the
>> specifics of the announcement at CiC came as a surprise to me. Nothing I said
>> should have been interpreted as broad support for a plan that I was aware of
>> only in the phrasing of "A Plan for Perl" (note: NOT the same as "THE Plan for
>> Perl").
>
> I apologize that the names on the document were not public.
>
>> I wonder how many other people in the list you consider "the decision having
>> been done with" have had their positionsmisunderstood or misrepresented by
>> you.
>
> We simply cannot make *everyone* happy because some of us have conflicting interests.

With respect, i think the main issue here is not the names on the list, or whether everyone's input was fully respected.

It appears from your original email that, whether intentionally or not, the original wording makes it appear that ether was a full, knowing, and approving part of the decisions that led to the original announcement. Her response however appears to indicate she was touched by the matter only tangentially.

This i feel is an important distinction as a lot of people with opinions on this might form opinions on ether, or other people you listed, that are unwarranted.

-- 
With regards,
Christian Walde
0
walde
7/4/2020 11:06:40 AM
On 7/4/20 2:06 PM, Christian Walde wrote:
> On Sat, 04 Jul 2020 11:54:16 +0200, Sawyer X <xsawyerx@gmail.com> wrote:
>
>>
>> On 7/4/20 7:37 AM, Karen Etheridge wrote:
>>> Sawyer said:
>>>
>>> > This decision was done with [...] this group includes [...] Karen 
>>> Etheridge
>>>
>>> I was certainly not aware of any
>>> specific action that was intended to be taken on a particular date, 
>>> and the
>>> specifics of the announcement at CiC came as a surprise to me. 
>>> Nothing I said
>>> should have been interpreted as broad support for a plan that I was 
>>> aware of
>>> only in the phrasing of "A Plan for Perl" (note: NOT the same as 
>>> "THE Plan for
>>> Perl").
>>
>> I apologize that the names on the document were not public.
>>
>>> I wonder how many other people in the list you consider "the 
>>> decision having
>>> been done with" have had their positionsmisunderstood or 
>>> misrepresented by
>>> you.
>>
>> We simply cannot make *everyone* happy because some of us have 
>> conflicting interests.
>
> With respect, i think the main issue here is not the names on the 
> list, or whether everyone's input was fully respected.
>
> It appears from your original email that, whether intentionally or 
> not, the original wording makes it appear that ether was a full, 
> knowing, and approving part of the decisions that led to the original 
> announcement. Her response however appears to indicate she was touched 
> by the matter only tangentially.
>
> This i feel is an important distinction as a lot of people with 
> opinions on this might form opinions on ether, or other people you 
> listed, that are unwarranted.
>

This is a fair point. I understand the confusion I caused.


My intention was to highlight that this decision was not done in a void 
and we did try to bring as many relevant people as we could. It was far 
from perfect, I'll grant that.
0
xsawyerx
7/4/2020 12:04:17 PM
Le 28/06/2020 � 21:01, James E Keenan a �crit�:
> On 6/28/20 1:23 PM, Christian Walde wrote:
>> On Fri, 26 Jun 2020 20:57:39 +0200, John Lightsey <john@nixnuts.net> 
>> wrote:
>>
>>> I'd love to see Perl 8 fix [...] Windows support.
>>
>> 2 things here:
>>
>> 1. Please don't phrase it in a way that implies Perl doesn't support 
>> windows. I've been developing Perl on windows for over a decade and it 
>> works.
>>
> 
> Unfortunately, the data available to us suggests we have problems 
> maintaining Perl on Windows in optimal condition.
> 
> Go to http://perl5.test-smoke.org/search and plug in "MSWin32" to the 
> OSname drop-down.� Observe a long list of FAILs.
> 
> Now, I grant you that it only takes one unit test failure in one test 
> file to grade the whole smoke-test run FAIL.� Nonetheless, we do a good 
> job of getting PASSes on Linux and at least 3 of the BSDs.
> 
> We need smoke-test reports preferably (a) from recent Windows releases 
> for the business environment; and (b) from testers skilled enough in, 
> and dedicated enough to, Windows to be able to diagnose failures and 
> work with us to fix them.
> 
> Thank you very much.
> Jim Keenan

I have tried several times but the link above does not seem to work for me.

As I have just written in an other thread, #120797 has AFAIK received no 
love since 2013. At the time it prevented Dist-Zilla, Pod-Weaver, 
Config-INI and others to install on Windows. I would not be too 
surprised if some of the failures above are related to that.

One possible way to check would be to try and install the failing 
distribs on a linux box but with PERLIO=crlf, and see whether this 
produces the same errors than on windows. Or to try on a windows box but 
with PERLIO=unix and see whether it passes (at the time I had almost 
succeeded in installing Dist::Zilla on windows with this trick). YMMV.

Best regards,

--Christian
0
cm
7/5/2020 9:55:14 PM
On Sun, 05 Jul 2020 22:58:38 +0200, Christian Millour <cm.perl@abtela.com> wrote:

> I have tried several times but the link above does not seem to work for me.
>
> As I have just written in an other thread, #120797 has AFAIK received no
> love since 2013. At the time it prevented Dist-Zilla, Pod-Weaver,
> Config-INI and others to install on Windows. I would not be too
> surprised if some of the failures above are related to that.

Those are Perl smoke reports, not CPAN.

Also see: https://www.nntp.perl.org/group/perl.perl5.porters/2020/06/msg257656.html

-- 
With regards,
Christian Walde
0
walde
7/5/2020 11:02:42 PM
Reply: