Front page | perl.perl5.porters |
Postings from June 2020
Re: Announcing Perl 7
Thread Previous
|
Thread Next
From:
Dan Book
Date:
June 29, 2020 01:00
Subject:
Re: Announcing Perl 7
Message ID:
CABMkAVWdZkuZciK2aaePQNmcdswjK-QEMOoXJ5Dfib+7wLVtGQ@mail.gmail.com
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.
>
> 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â 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.
>
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
Thread Previous
|
Thread Next