> I find nothing in the documentation that suggests that => is
> anything other than a plain comma operator, yet you call it a
> "first-argument-stringifying comma operator". In fact, the
> documentation explicitly claims "=>" is a synonym of "," (see
> perldata).
The Perl documentation contains only a second approximation to Perl. :-)
The perl interpreter contains the first approximation.
(For those who are wondering: Larry's brain contains the zero'th approximation)
> So I'm curious where you get this from,
>From the fact that => currently converts any bareword left operand to a string.
> and what you mean by it,
That => currently converts any bareword left operand to a string.
> and whether it is relevant to this RFC.
Yes, because it's proposed that this aspect of =>'s behaviour be preserved.
> > Note that these semantics still support the popular:
> > [SNIP]
>
> But not the (safer) alternative:
> [SNIP]
Sure they do. p52p6 would handle the change in semantics by mapping
every Perl 5 instance of:
bareword => $whatever
to:
'bareword', $whatever
and every remaining instance:
$non_bareword => $whatever
to:
$non_bareword, $whatever
> With an appropriate prototyping system, perhaps pairs would be
> useful for named scalar arguments to subs. Quite a few have
> complained about missing the $ in other named parameter proposals
> though,
And they're wrong. :-)
The variables *shouldn't* appear in the calling scope, only their *names*.
> and pairs neither help that, nor provide help for passing
> arrays or hashes by name.
This can be correctly handled. The named parameter's context specifier
would be propagated to the right operand of the =>. So:
sub demo ( $name, \%options ) {...}
will accept:
demo(options=>%myopts, name=>'my name');
because the C<\%> prototype for the parameter <\%options> will be
propagated to the right operand of C<options=>%myopts>, causing it
to act like C<options=>\%myopts>.
Damian
