>Maybe there will be a Perl 6 rule forcing the keys to be quoted, but it
>won't be because of the "no barewords" rule. If there were such a rule, I
>presume you'd also apply it to the LHS of =>?
There is another way to resolve the ambiguity of foo meaning either
"foo" or foo() depending on current subroutine visibility. This
would also extend then to issue of $hash{foo} meaning either
$hash{foo()} or $hash{"foo"}. Just use parens.
Oh, I know, I know. I can already hear the mass reaction now: "Oh,
horrors!" cry the masses from every timezone. But let's think about
it anyway.
Perl's historical optionality of explicit parentheses to delimit a
function's argument list is, like its similar optionality of explicit
quotation marks, a source of ambiguity. And while ambiguity can
be a source flexibility, expressibility, and convenience, it can
also have a darker side that would be better relegated to obfuscated
programming contests than to production-calibre code.
In my experience, many programmers would prefer that all functions
(perhaps restricted to only those of no arguments to appease
hysterical cetaceans?) mandatorily take (even empty) parens. Thus,
shift() in lieu of shift, no matter whether it's as a hash subscript
or the left-hand operand of the comma arrow, or whether it's floating
around free, outside of any such autoquoting construct.
Since this matter has now been mentioned, I would like to suggest that
there lurk other related and perhaps even more important ramifications to
the current optionality of parentheses than the one concerning strings.
Witness:
% perl -MO=Deparse,-p -e 'push @foo, reverse +1, -2'
push(@foo, reverse(1, -2));
% perl -MO=Deparse,-p -e 'push @foo, rand +1, -2'
push(@foo, rand(1), -2);
% perl -MO=Deparse,-p -e 'push @foo, time +1, -2'
push(@foo, (time + 1), -2);
[ Gr. That should read time(). ]
% perl -MO=Deparse,-p -e 'push @foo, fred +1, -2'
push(@foo, ('fred' + 1), -2);
Do you see what I'm talking about? The reader unfamiliar with the
particular context coercion templates of the functions used in code
like
use SpangleFrob;
frob @foo, spangle +1, -2;
can have no earthly idea how that will even *parse*. This situation
seems at best, unfortunate.
I'm sure that if it were somehow possible to require proper placement of all
those parens, even with something like the hypothetical and wholly optional
"use strict 'parens'", that this would raise the hackles of many a current
Perl programmer. But perhaps this owes more to the fact that those folks
do not have to explain or justify this particular--well, let's be charitable
and merely call it an "issue"--to those whom it befuddles or annoys than it
owes to any legitimate convenience or desirable functionality. When you get
to see non-wizards repeatedly stumble on these ambiguities on a regular basis,
this whole situation can quickly become a source of frustration, embarrassment,
or both. Whether this scenario inspires apologetics or apoplectics is not
consistently predictable.
However, if one were simply *able* to write something like
use SpangleFrob;
use strict 'parens'; # subsumed within a blanket "use strict"
frob(@foo, spangle(1, -2));
frob(@foo, spangle(1), -2);
frob(@foo, spangle() + 1, -2);
then, without even inflicting grievous harm on compile-time checking of
arguments, one could at least always readily discern which arguments went
where--which hardly seems an undesirable goal, now does it?
Nevertheless, even that wouldn't help in being able to know whether
that's really meaning
frob( @foo, ....
frob( \@foo, ....
frob( scalar @foo, ....
It all would depend upon the existence of coercion templates such
as frob(@...), frob(\@...), and frob($...). Sadly, there's no
B::Deparse switch to tell you under which scenario your operating,
but that's all probably best left for a semi-separate discussion
(if at all).
The devil's advocate might suggest that not knowing which of the
three treatments of @foo silently occurred in the frobbing function
call--which they with some credibility assert a desirable goal--goes
hand in glove with not knowing whether spangle is here acting as a
list-op, as a un(ary)-op, or as a non(e)-op. But considering that
such devils need no help in their advocacy, I shan't bother to do
so myself. :-)
--tom
