From @tene

Rakudo currently passes positional arguments into named parameters of
functions. This is in violation of S06​:748.

sub a (​:$a) { say $a }

a(1);

Possibly related, this also does the wrong thing​:

multi sub t ($a) { say 'one positional' }
multi sub t ($​:a) { say 'one named' }

t(1);

Prints​: "one named".

From @pmichaud

On Wed, May 07, 2008 at 02​:12​:00AM -0700, Stephen Weeks wrote​:

Rakudo currently passes positional arguments into named parameters of
functions. This is in violation of S06​:748.

sub a (​:$a) { say $a }
a(1);

There's a somewhat significant mismatch between Perl 6's handling of
arguments and Parrot's handling of them; at the moment Rakudo
is following the Parrot conventions.

My guess at this point is that unless/until Parrot updates its
calling conventions, Rakudo will at some point generate most of
its subs as

  .sub 'a'
  .param pmc positional :slurpy
  .param pmc named :slurpy :named
  ...

and then generate code to bind positional/named arguments to
local lexicals according to P6 conventions.

Possibly related, this also does the wrong thing​:

multi sub t ($a) { say 'one positional' }
multi sub t ($​:a) { say 'one named' }
t(1);

Prints​: "one named".

I suspect Parrot's MMD here, and since Parrot MMD is due for an
overhaul (pdd27) we'll probably accept this for a while.

Thanks!

Pm

The RT System itself - Status changed from 'new' to 'open'

From @tene

Not long ago, Patrick R. Michaud via RT proclaimed...

There's a somewhat significant mismatch between Perl 6's handling of
arguments and Parrot's handling of them; at the moment Rakudo
is following the Parrot conventions.

My guess at this point is that unless/until Parrot updates its
calling conventions, Rakudo will at some point generate most of
its subs as

\.sub 'a'
    \.param pmc positional :slurpy
    \.param pmc named      :slurpy :named
    \.\.\.

and then generate code to bind positional/named arguments to
local lexicals according to P6 conventions.

Won't that cause problems with signatures for MMD?

From @pmichaud

On Wed, May 07, 2008 at 08​:11​:28AM -0600, Stephen Weeks wrote​:

Not long ago, Patrick R. Michaud via RT proclaimed...

There's a somewhat significant mismatch between Perl 6's handling of
arguments and Parrot's handling of them; at the moment Rakudo
is following the Parrot conventions.

My guess at this point is that unless/until Parrot updates its
calling conventions, Rakudo will at some point generate most of
its subs as

\.sub 'a'
    \.param pmc positional :slurpy
    \.param pmc named      :slurpy :named
    \.\.\.

and then generate code to bind positional/named arguments to
local lexicals according to P6 conventions.

Won't that cause problems with signatures for MMD?

It might. As I said, there's a somewhat significant mismatch, and
I haven't thought it completely through yet because we haven't
quite reached that point (although we're getting very close to it).

Another example of a mismatch is that named parameters in Perl 6
can be applied to positionals. For example, consider

  sub foo($x, $y) { say "$x $y"; }

Each of the below calls to foo produce the same results​:

  foo(1, 2);
  foo(​:x(1), :y(2));
  foo(​:y(2), :x(1));
  foo(y=>2, x=>1);

Note that even though $x and $y are required positional parameters,
they can still be bound using named arguments. However, Parrot
calling conventions keep positional and named arguments completely
separate, which makes things somewhat complex. This means that
Rakudo will likely have to work around this somehow -- and yes,
that means that pdd27 MMD might not work out for Rakudo. In that
case Rakudo may just end up layering its own ideas of MMD
on top of/in place of whatever Parrot is providing at the core
level.

(We may want to re-think Parrot's calling conventions altogether,
especially in light of efficiency concerns, but there hasn't
been much progress/traction on that point yet.)

Pm

From @diakopter

sub foo($w, $x?, $y?, :$z = 2){ say $w~"|"$x"|"$y"|"~$z};
foo(1,Undef,Undef,'something_extra',​:z(3));

OUTPUT[1|Failure|Failure|something_extra␤]

the 'something_extra' should have been disregarded entirely. I
expected​: OUTPUT[1|Failure|Failure|3␤]

Note also that pugs gives​: OUTPUT[*** No compatible multi variant
found​: "&foo"␤ at /tmp/BwplDZyBLJ line 1, column 63-105␤] (for the
same thing except with Undef in lowercase)

From @diakopter

14​:12​:49 < diakopter> rakudo​: sub foo(​:$w=4){say $w.perl}; my
%z=​:x(7); foo(%z); # I guess named arguments fall back to
  being positional ones...?
14​:12​:51 < ?? exp_evalbot ??> OUTPUT[​:x(7)␤]

foo(%z) should be invoking foo with %z as a positional argument, and
foo() expects a named argument, but foo's $w receives %z.

From @pmichaud

On Sun, May 25, 2008 at 10​:34​:25AM -0700, diakopter wrote​:

# New Ticket Created by diakopter
# Please include the string​: [perl #​54802]
# in the subject line of all future correspondence about this issue.
# <URL​: http://rt.perl.org/rt3/Ticket/Display.html?id=54802 >

sub foo($w, $x?, $y?, :$z = 2){ say $w~"|"$x"|"$y"|"~$z};
foo(1,Undef,Undef,'something_extra',​:z(3));

OUTPUT[1|Failure|Failure|something_extra␤]

the 'something_extra' should have been disregarded entirely. I
expected​: OUTPUT[1|Failure|Failure|3␤]

I would expect 'something_extra' to generate an exception,
as sub 'foo' can only accept 1 to 3 positional arguments.

As far as what is happening with Rakudo above,
the problem here appears to be that parrot quietly binds
named parameters to extra positional arguments. I've noted
this and requested a clarification on parrot-porters -- as soon
as that's resolved we'll be able to come up with a solution for
Rakudo.

Also, as far as I can tell "Undef" isn't really a valid type
in Perl 6 -- rakudo was improperly mapping it to "Failure".
Now it just returns the Undef namespace that Parrot has as
part of its internals (which will disappear from rakudo's
environment when we switch to using HLL namespaces).

Note also that pugs gives​: OUTPUT[*** No compatible multi variant
found​: "&foo"␤ at /tmp/BwplDZyBLJ line 1, column 63-105␤] (for the
same thing except with Undef in lowercase)

Pugs does what I would expect -- i.e., complain that it can't
find a 'foo' that accepts four positional parameters.

Pm

The RT System itself - Status changed from 'new' to 'open'

From @pmichaud

On Sun, May 25, 2008 at 12​:18​:28PM -0700, diakopter wrote​:

# New Ticket Created by diakopter
# Please include the string​: [perl #​54810]
# in the subject line of all future correspondence about this issue.
# <URL​: http://rt.perl.org/rt3/Ticket/Display.html?id=54810 >

14​:12​:49 < diakopter> rakudo​: sub foo(​:$w=4){say $w.perl}; my
%z=​:x(7); foo(%z); # I guess named arguments fall back to
being positional ones...?
14​:12​:51 < ?? exp_evalbot ??> OUTPUT[​:x(7)␤]

foo(%z) should be invoking foo with %z as a positional argument, and
foo() expects a named argument, but foo's $w receives %z.

The primary problem here is the same as the one given in RT#​54802 --
namely, Parrot binds named arguments to any extra positional parameters.
So, I'm going to merge this ticket with that one.

Beyond that, at the moment Rakudo doesn't really understand
hashes or list context, so the statement my %z = :x(7); is
really initializing %z to be Pair instead of a Mapping (and that
Pair is then being passed as an argument to foo).

Thanks,

Pm

The RT System itself - Status changed from 'new' to 'open'

From @moritz

To the best of my knowledge this is solved in Rakudo 9d76f3, and we have
passing tests, so I'll close this ticket.

@moritz - Status changed from 'open' to 'resolved'