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.
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.
-A*a
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.
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.
-A*a