[perl #53814] Named/Positional dispatch confusion

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


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

On Wed, May 07, 2008 at 02:12:00AM -0700, Stephen Ws 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

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?

On Wed, May 07, 2008 at 08:11:28AM -0600, Stephen Ws wrote:
> Not long ago, Patrick R. Michaud via RT proclaimed... 
>
> 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