Same-named arguments

[Michael Snoyman]

I asked this same question on perl6-users, but no one really seemed to have
a definitive answer, so please forgive me for reasking.

I was wondering how named arguments would work when parameters of different
types had the same name, ie sub foo($bar, @bar, &bar) {...}. I wrote a
little script to test it out and ran it through pugs. Here's the results:

Hi,

I'm just starting with Perl 6. I was reading through "Perl 6 and Parrot
Essentials" (finally arrived yesterday from Amazon; very happy) and I was
wondering what would happen if you had a parameter list that included
variables of a different type but the same name (ie, $foo, @foo). I wrote a
little test script and ran it through pugs. Here's what I got:

Script:

use v6;

sub mysub($foo, @foo, %foo) {
say "Starting mysub";
say "Printing scalar";
say $foo;
say "Printing array";
say @foo;
say "Printing hash";

say %foo;
say "Leaving mysub\n";
}

my $foo = 'foo';
my @foo = qw|foo bar|;
my %foo = ( foo => 'bar', foo2 => 'bar2' );

mysub($foo, @foo, %foo);
mysub(:foo($foo), :foo(@foo), :foo(%foo));

Output:

Starting mysub
Printing scalar
foo
Printing array
foobar
Printing hash
foo barfoo2 bar2
Leaving mysub

Starting mysub
Printing scalar
foo
Printing array

Printing hash

Leaving mysub

Just wondering if the language is meant to work that way, or if it's a pugs
"feature."

Thanks,
Michael

[Luke Palmer]

On 8/25/06, Michael Snoyman <michael...@ucla.edu> wrote:
> I asked this same question on perl6-users, but no one really seemed to have
> a definitive answer, so please forgive me for reasking.
>
> I was wondering how named arguments would work when parameters of different
> types had the same name, ie sub foo($bar, @bar, &bar) {...}.

That's probably an error at compile time, given the new provision that
'@bar' => ... is not a named argument so we have no way to distinguish
between the parameters.

Luke

[mark...@mail.com]

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.

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?

I freely admit to myopia and a lot less time thinking about this
stuff, but using extra parens or autoquoting vs explicit quotes to
distinguish named params from pair arguments feels wrong.

--
Mark J. Reed <mark...@mail.com>

[Audrey Tang]

2006/8/26, mark...@mail.com <mark...@mail.com>:

> 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

[mark...@mail.com]

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.

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?

I freely admit to myopia and a lot less time thinking about this

stuff, but using extra parens or autoquoting vs explicit quotes to
distinguish named params from pair arguments feels wrong.

On 8/25/06, Luke Palmer <lrpa...@gmail.com> wrote:

[mark...@mail.com]

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.

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?

I freely admit to myopia and a lot less time thinking about this
stuff, but using extra parens or autoquoting vs explicit quotes to
distinguish named params from pair arguments feels wrong.

On 8/25/06, Luke Palmer <lrpa...@gmail.com> wrote:

[Michael Snoyman]

>
> 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.

I was discussing this with a friend of mine (Eric Livak), and he suggested
making the sigil on the name optional for disambiguation. I was wondering
if there's a possibly a way to automatically determine which parameter to
pass to based on the type of the argument. Since I'm really not that
well-versed on the language, and definitely know nothing about the
internals, I don't know if that's asking the impossible, but it seems to me
like a simple solution.

Michael

[Mark J. Reed]

On 8/26/06, Audrey Tang <audre...@gmail.com> wrote:
> 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.

Allow me to make an immodest proposal. Have named parameter passing
look like this:

':' . param name (including sigil) . ( '(' . value . ' )' x (0|1)).

So func('&x' => 1) would become func(:&x(1)). The colon would
consistently have the effect of "preventing evaluation" of the key (as
it currently does by having :foo(1) not call foo()).

The call foo(:$bar($baz)) would assign the value of the variable $baz
to the named parameter '$bar" and would have nothing to do with the
caller's $bar variable, although it could default to that so that
foo(:$bar) would still have its current semantics.

Perhaps the sigil could be optional when there is only one parameter
matching the rest of the name, or else the callee's signature would be
able to specify that the sigil is optional.

I would then make key => value always be a Pair value. For module
writers to support perl5 calling semantics, I'd prefer a mechanism for
asking for that explicitly in the signature rather than jumping
through hoops to support it by default. Perhaps there could be a rule
that, in the absence of a slurpy hash declaration, any trailing Pairs
are scanned for matches to named parameters?