develooper Front page | perl.perl5.porters | Postings from May 2021

Re: Two further features, one definitely needed for survival, otherlikely needed.

Thread Previous | Thread Next
From:
Tomasz Konojacki
Date:
May 23, 2021 20:00
Subject:
Re: Two further features, one definitely needed for survival, otherlikely needed.
Message ID:
20210523220034.506C.5C4F47F8@xenu.pl
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

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About