Re: RFC 57 (v1) Subroutine prototypes and parameters

Perl6 RFC Librarian <[email protected]> writes:
> This has a dangerous and unpredictable side-effect which we would rather 
> avoid.  So the third and preferred candidate is: 
> 
>     foo(x = 10, y = 20);
> 
> In Perl 5 this is a syntax error raising a 'Bareword "x" not
> allowed...'  error message.  This is a Good Thing because it implies
> there aren't (m)any existing scripts that are currently using this
> construct.  


    sub x : lvalue { $x }
    sub y : lvalue { $y }

    foo(x = 10, y = 20);

However, I note that:

    foo(x:10, y:20) 

throws a syntax error, as does:

    foo($x:10, $y:20)

Hey! So does:

    foo($x := 10, $y := 20)

But that looks painful.

I also note that given  

     sub ($x, $y, $z) { #stuff
     }

It might be nice if:

     $curried_foo = foo(x:10, y:20);

returned an appropriately curried function... But Damian's already
doing curries elsewhere...

> RFC 9 proposes "Highlander Variables" in which C<$y> is implicitly a
> reference to C<%y> or <@y>. This would allow lists and hashes to be
> passed by reference as named parameters to the same effect. This is
> preferable to the above, (in the author's opinion) because the
> different types are more clearly disambiguated.

Note that, if the foo($x:1, @y:(1, 2, 3)) option is taken this removes
the 'requirement' for Highlander Variables, which in this author's
opinion can only be a good thing.

I would be inclined to argue that mixing named and positional calling
idioms should be a syntax error, or at the very least should trigger a
warning.

-- 
Piers