John Porter wrote:
> undecorated variable names suffer from this showstopping weakness:
> they can't be interpolated. Unless we change other aspects of perl's
> syntax to support it, that is -- maybe s/${x}/5/. Now, maybe we can
> live without variable interpolation; but I'd bet most perl programmers
> would rail against that.
Now we're covering the same ground I covered with Nathan Wiger.
I am not suggesting dropping the magic signifiers from the beginning of
Perl scalars and containers. In fact, I resent these insinuations
(first Nathan's, now yours) that I am among those who suggest dropping the
decorations from perl scalars. I am not among that group.
Languages with undecorated variable names do not allow their interpolation.
Even if we allow some undecorated variable names as usable, those names will
still be undecorated, and will not interpolate without special treatment.
There are alternatives to interpolation, for instace sprintf().
Interpolation, as such, requires the variable names to be %decorated% somehow.
Bareword, or Undecorated, variables, such as perl 5.6's legal (as I understand it)
sub undecorated() : lvalue {
return $undecorated_stash_package::some_obscure_name;
}
do not interpolate.
C<qq//> interpolation will still require the syntactic clue of variable name
decoration to operate, even if a human brain does keep a short list of recently
used referent names and interpolates them as needed for better compliance with
projected remote schema based on experience.
That trick is beyond the scope of what I believe are suggestions for reasonable
incremental improvements to a programming language.
That is where I draw the line.
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
perl -e'map{sleep print$w[rand@w]}@w=<>' /usr/dict/words
