Larry Wall writes:
> On Fri, Aug 20, 2004 at 04:15:43PM -0600, John Williams wrote:
> :
> : say .meth :foo; # say( .meth( foo=>1 ) )
>
> That one works.
But that's because :foo is an adverb to .meth, not because .meth is
taking an argument 'foo' => 1, right?
> Likewise
>
> sqrt($x):both
>
> could return both the positive and negative root. In this case it's
> ambiguous whether
>
> sqrt $x, :both
>
> should treat sqrt as a named unary or a list operator. I don't know
> offhand which way to bias that, or whether the parser should just
> throw up its hands in disgust. Or just throw up...
Well, in this case, I'd be tempted to look at which one's more likely to
blow up sooner when you do it wrong. If we have:
my $root = sqrt $x, :both;
And it assumes sqrt is unary, then you get the equivalent of:
my $root = [ sqrt($x), 'both' => 1 ];
If you have the extremely unlikely:
my $list = sqrt $x, :foo;
Then you get a "sqrt doesn't know what :foo means". That combined with
the fact that you'll much more rarely see a function call followed by a
pair, I like that better. On the other hand:
my @check = splice @nums, 0, sqrt $max, :something
:something looks an awful lot more like an argument to splice than to
sqrt. But again, sqrt will probably blow up immediately, and you can
fix it. So making it a list op looks far advantageous. That's also an
argument against using the slurpy hash whenever you can manage.
> : Do I have my whitespace rules right below?
> :
> : say foo :bar; # say( foo( bar=>1 ) ) assuming foo is listy
> : say .foo :bar; # say( .foo( bar=>1 ) )
> : say foo: bar; # foo.say(bar)
>
> Yes, but works only if "foo" is predeclared as a class.
Or function name.
> : say foo:bar ; # ?? say foo :bar ??
>
> Yes, like the label colon, the invocant-terminating colon requires
> whitespace after it if it would be confused with a longer term starting
> with colon. And /^\:\w+/ is always a named pair of some sort. Otherwise
> we couldn't string together :foo:bar:baz:utf($ate).
This nice effect is a result of the fact that Perl will use a tokenizer
at this level. :bar will get tokenized before : will, so that's how
it's interpreted.
> : Larry also shows this example:
> :
> : > @a.sort:quick:{ +$_ } # both adverbs apply to .sort
> :
> : Would that work for the functional form too?
> :
> : sort :quick :{ +$_ } @a;
>
> Not unless you put a comma after the closing curly. Otherwise it's
> expecting an operator.
Very nice. I was worried about that one, too, where list operators with
their first argument a closure would require options between the closure
and the list, which feels wrong (to me). That's assuming that you can
declare:
sub sort(*&code, +$quick, [EMAIL PROTECTED]) {...}
Perhaps if there's only one &something argument, it automatically
becomes *&something as to aid usability?
Luke
