2006/8/26, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
So what's the rationale behind the latest changes? I thought p6
consistently regarded the sigil as part of the name; seems like that
should go for named parameters, too. In fact, sigils would seem to be
a good way to distinguish named parameters from pairs.
Mostly, it's that func('&x' => 1) requires a bit too much typing, and also
makes it hard for func() to change its signature later on to accept things
other than Code.
Alternatively, reserve either :k(v) or k=>v for named parameters and
use the other for pairs. I don't see the value of conflating those two
things syntactically - is it just for compatibility with p5 modules
that take their parameters as hashes?
Indeed. Were it not for Perl5, I think forcing people to always write
:named($param) instead of named=>$param is a cleaner solution.
The rationale behind autoquoting-as-named is that, the autoquoted
identifiers are the same set of names you can use on the signature line:
func("Some string with embedded space" => $value);
would be taken as Pair, not named, because one cannot declare a
parameter name that contains space in &func's signature line.
On the other hand, I'd have no problem with parens-disambiguation going
away, such that f((((x=>1)))) means just f(x=>1), and use f('x'=>1) when
you mean a Pair.
Cheers,
Audrey
