*inline*
On 4/11/21 2:15 PM, B. Estrade wrote:
>
>
> On 4/11/21 1:44 PM, Darren Duncan wrote:
>> On 2021-04-11 8:35 a.m., Joseph Brenner wrote:
>>> I have a suggestion on that front: what if we set things up so
>>> that the new features can be invoked by running "perl7" instead
>>> of something like
>>>
>>> perl -Mv7.0
>>>
>>> This may seem like a very trivial change, but I think you can see
>>> cases where trivial changes like this succeed in capturing some
>>> mind share. There's a huge difference between "you can do that
>>> easily" and "you can do that trivially".
>>
>> Having separate "perl7" binaries was discussed before and amounts to a
>> fork of Perl. I strongly disagree with "perl7", it is proper for the
>> code itself to contain a declaration of the expected Perl version,
>> because then it will do the right thing implicitly for everyone with a
>> copy of that code. -- Darren Duncan
>
> A practical downside to multiple binaries also comes into play with the
> distribution on OSes and different package managers.
>
> Only FreeBSD maintains a "moving" window of things (not just perl, there
> are many examples like, python37, python38, etc).
i.e., with only one sharing a the canonical symlink at any given time
(e.g., /usr/bin/local/perl -> /usr/local/bin/perl5.32.0
It is notable that it handles python differently, e.g. (on a system I
have immediate access to):
/usr/bin/local/python2.7 (no symlink)
/usr/local/bin/python3.7 (no symlink)
/usr/local/bin/python3.7m (whatever that is, no symlink)
However, there are symlinks for things I have no idea about):
/usr/local/bin/python3.6-config -> /usr/local/bin/python3.6m-config
/usr/local/bin/python3.7-config -> /usr/local/bin/python3.7m-config
>
> OpenBSD has a base perl, and only 1 base perl, per release.
>
> Etc.
>
> In terms of distribution, this must be well understood and considered.
> So I am personally also against the idea of multiple versions.
oof,
*s/multiple versions/multiple binaries/*
>
> And if that is not enough to sway, then consider the mistakes other
> interpreted languages have made. Whether you think some have made
> mistakes or not, it still is prudent to learn from others' mistakes. We
> have our fair share of our own to learn from; we sure don't need more.
>
Brett
On 4/11/21 2:15 PM, B. Estrade wrote:
>
>
> On 4/11/21 1:44 PM, Darren Duncan wrote:
>> On 2021-04-11 8:35 a.m., Joseph Brenner wrote:
>>> I have a suggestion on that front: what if we set things up so
>>> that the new features can be invoked by running "perl7" instead
>>> of something like
>>>
>>> perl -Mv7.0
>>>
>>> This may seem like a very trivial change, but I think you can see
>>> cases where trivial changes like this succeed in capturing some
>>> mind share. There's a huge difference between "you can do that
>>> easily" and "you can do that trivially".
>>
>> Having separate "perl7" binaries was discussed before and amounts to a
>> fork of Perl. I strongly disagree with "perl7", it is proper for the
>> code itself to contain a declaration of the expected Perl version,
>> because then it will do the right thing implicitly for everyone with a
>> copy of that code. -- Darren Duncan
>
> A practical downside to multiple binaries also comes into play with the
> distribution on OSes and different package managers.
>
> Only FreeBSD maintains a "moving" window of things (not just perl, there
> are many examples like, python37, python38, etc).
i.e., with only one sharing a the canonical symlink at any given time
(e.g., /usr/bin/local/perl -> /usr/local/bin/perl5.32.0
It is notable that it handles python differently, e.g. (on a system I
have immediate access to):
/usr/bin/local/python2.7 (no symlink)
/usr/local/bin/python3.7 (no symlink)
/usr/local/bin/python3.7m (whatever that is, no symlink)
However, there are symlinks for things I have no idea about):
/usr/local/bin/python3.6-config -> /usr/local/bin/python3.6m-config
/usr/local/bin/python3.7-config -> /usr/local/bin/python3.7m-config
>
> OpenBSD has a base perl, and only 1 base perl, per release.
>
> Etc.
>
> In terms of distribution, this must be well understood and considered.
> So I am personally also against the idea of multiple versions.
oof,
*s/multiple versions/multiple binaries/*
>
> And if that is not enough to sway, then consider the mistakes other
> interpreted languages have made. Whether you think some have made
> mistakes or not, it still is prudent to learn from others' mistakes. We
> have our fair share of our own to learn from; we sure don't need more.
>
Brett