> I kinda like it. It's... intuitive. It makes named sub arguments rather
> straightforward, apart from that prefix thing.
>
> Should (name => 'Bart') really stuff 'Bart' into a lexical variable
> $name? That's... odd.
Not really. If (name=>'Bart') is an arg list, it probably stuffs 'Bart' into
a lexical variable already (via an explicit C<my %args = @_>).
> I see no connection between 'name' and '$name', but I'm trying
> really hard to ignore any similarities.
They're more alike that name and $args{name}, and people cope with that.
They're more alike that *{name}{SCALAR} and \${name}, and (some) people
cope with that too.
> You have overlooked one reference: RFC 21, "Replace C<wantarray> with a
> generic C<want> function", by... you. :-) I understand that a pair would
> behave differently in array context (may I call it that?) than in a hash
> context.
That's not how I think of it.
The difference is how a hash and an array *interpret* a PAIR that's assigned to
them. The hash unwraps the pair and stores the value under the key. Teh array
just stores the PAIR as a reference (as it would any other type of reference).
> What about the current habit of passing arguments using the "-bareword
> => $value" syntax, to unprototyped subs? Is this an array or a hash
> context? Or does it not matter?
The distinction doesn't exists, so it (probably) doesn't matter :-)
> In case you're wondering, I am thinking
> about backward compatibility of current modules on CPAN that use this
> syntax, whether these would still work under Perl6, or whether they'd
> need a rewrite. (ugh!)
p52p6 would handle it (by translating all Perl 5 C<x=>"y">'s to Perl 6
C<'x',"y">'s.
I *must* put this in the RFC!
Damian
