On Fri, Aug 20, 2004 at 06:12:06PM -0600, Luke Palmer wrote:
: 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?
Correct.
: > 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.
Agreed. It's not likely to be a big problem either way unless we go
nuts on trying to give consistent modifier names to different sorts
of operators. In particular we should probably try to avoid giving
adverbial arguments to things like assignment and comma.
: > : 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.
Righto. Actually, it always assumes listop for an unrecognized bareword,
so we have to make sure it never eats the colon that indicates indirect
object.
: > : 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.
Or at least, the parser functions as a tokener at this level.
: > : 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?
Maybe...have to think about the pragmatic ramifications of that.
Larry
