Re^4: Perl6 Contest #2: P6 That Doesn't Look Like P5

[tall_man]

I was looking for ways to pass out-of-band parameters to the loop subroutines (preferably without requiring the users to make messy changes), and this idea of using named parameters in combination with a splatted list occurred to me.

#!/usr/bin/pugs

use v6;
#use Test;
#plan 2;

sub oob(+$x = $CALLER::_, *@lst) {
   return ($x,@lst);
}

sub runner() {
   $_ = "qqq";
   oob("a","b","c");
}

my ($x, @lst) = runner();
say "x = *$x* lst = *",~@lst,"*";
#is($x, 'qqq', '... default named parameter with $CALLER_ and a list',
+ :todo<bug>);
#is(~@lst, 'a b c', '... list after default named parameter with $CALL
+ER_', :todo<bug>);

What I actually got was:

x = *a* lst = *b c*

and not:

x = *qqq* lst = *a b c*

This was unexpected after seeing examples in E06, so it could be a bug test (with the Test stuff uncommented). Or I may be completely misunderstanding positional parameters.

[eric256]

Couldn't you place named paramteres after the uhhh....splatted?... parameter?

Actualy a quick test shows that doesn't work. I think however it would be usefull to have a set of positional paramters (like your slurpy array) and then follow them with parameters that are meant to be set by named pairs. Then sub oob(*@lst,?$x = $CALLER::_) { would DWIM

[tall_man]

I don't believe it will ever be possible to put named parameters after slurpy parameters. From E06:

An important restriction on named arguments is that they cannot come before positional arguments, or after any arguments that are bound to a slurpy array. Otherwise, there would be no efficient, single-pass way of working out which unnamed arguments belong to which parameters. But apart from that one overarching restriction (which Larry likes to think of as a zoning law), we’re free to pass named arguments in any order we like. That’s a huge advantage in any subroutine that takes a large number of parameters, because it means we no longer have to remember their order, just their names.

So this looks like the reason for my bug also. Named parameters cannot come before *@lst (because it's positional) and they cannot come after (because it's slurpy) so the declaration is invalid.

By the way, the "+" for "named only" doesn't really mean it. I found this astonishing code in the test cases:

sub foo (+$x = 3) { $x }
is(foo(4), 4, "using a named as a positional works");

If that is legal, what's the difference between a "+" prefix and a "?" prefix on a parameter?

[TimToady]

It is not legal, and the test case is in error.