Front page | perl.perl5.porters |
Postings from June 2020
Re: Announcing Perl 7
Thread Previous
|
Thread Next
From:
David Mertens
Date:
June 29, 2020 19:53
Subject:
Re: Announcing Perl 7
Message ID:
CA+4ieYUt6vKnRAsWbJHV4zZLOVHxJz1Uz-zMqC=uOO+DX0AfFA@mail.gmail.com
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
Thread Previous
|
Thread Next