Front page | perl.perl5.porters |
Postings from May 2021
On Sun, 23 May 2021 12:33:58 -0700
L A Walsh <astara@tlinx.org> wrote:
> Besides fixing the language incompatibility introduced by the removal of
> auto-deref, 2 other features largish features are on my table. I'm not
> certain how difficult they are, but such is life.
>
> 1) Making future perl-libs backward compatible so programs don't need
> rebuilding of their binary parts.
>
> Precedent: libc (glibc). Apparently it has been the case for some time,
> but as each new version of glibc is introduced, brought about by some
> incompatibility in the new API, the old API's are listed as being
> satisfied within the new library. I.e. programs built against
> glibc-X are guaranteed to run with glibc-X+1, +2, +3...
>
> This would imply that new versions of libperl-5.x would be useable by
> programs built against earlier versions. This would be a forward
> compatibility from some specific perl version, going forward.
>
> It may be that it would start with 5.34, such that progs built
> against 5.34 work with perl-lib 5.36. Going back before 5.34 would
> be a separate issue on a version/by/version basis.
This isn't happening. Maintaining binary compatibility between *minor*
releases is already problematic, see [1] for a recent example, so we
*definitely* aren't going to extend our guarantees even further.
> 2) Going 'unnecessary-sigil' optional.
>
> If a symbol has a unique type (SCALAR, sub, HASH, etc), and is declared
> before use by 'whatever appropriate mechanism', and there is no introduced
> ambiguity, then the sigil can be left off. In any case of ambiguity or
> where the same symbol is used with more than one type, or where the symbol
> isn't defined, a sigil would be required in the same way it currently is.
>
> There are likely sub-issues associated with this, but past programs, that
> use sigils would continue to execute the way they do now (compatibility).
>
> Only programs observing safe definitions & restrictions would be able
> to make use of the new syntax.
>
> This would allow a perl program to be much less busy and less complicated as
> users wouldn't need to to prepend sigils to everything (possibly only to
> calls/usages of old code).
>
> Of course, this is taking perl's knowledge of the type of a 'symbol'
> to the next logical step. If a new program doesn't over-define a symbol
> to be of more than one type, it wouldn't need sigils to disambiguate them.
> It does require that all symbols be defined so perl knows their type.
>
> For many users -- especially new users, this new semantic would eliminate the
> largest single complaint about perl.
>
> Fortunately or unfortunately, I believe you'll find auto-deref to be
> "assumed" to work, since if one has a sigil-less symbol, you have even
> less type-syntax (in the form of a sigil prefix) than you would with
> auto-deref. I didn't dream up this idea of sigil-less syntax to support
> auto-deref, but I have seen restoring auto-deref as a necessary step, as
> well as being consistent with current perl syntax supporting random-access
> item dereferencing. ($aref->[X], $href->{X})
>
> It may not seem like a sexy research topic, but I do believe it to be
> necessary to save the language from its largest criticism.
https://www.nntp.perl.org/group/perl.perl5.porters/2021/05/msg260068.html
[1] - https://github.com/Perl/perl5/issues/17154