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