On Sat, Aug 14, 2004 at 12:32:30AM -0400, Joe Gottman wrote:
: Doesn't the concept of an anonymous named param (in the fourth and fifth
: examples above) seem like an oxymoron? If it's anonymous it can't have a
: name (or at least we can't know its name).
It's anonymous only in the sense that the caller doesn't know that
callee's declared name for the slurpy function, just as when you say
push @foo <== 1,2,3
the caller doesn't know what push calls its slurpy list.
: More importantly, what is an anonymous named param used for?
It's for passing a closure argument without having to put parens
around it. I think that's about all it's good for. Though arguably
it'd be nice to allow a slurpy scalar that lets the PDL folks
write something like
[1..10:(3)]
to mean
[1..10:by(3)]
Except then they'll want to write
[1..10:3]
and then they'll get completely confused when
[1..10:int($y)]
doesn't work. So maybe we force them to say "by".
: Also, suppose I have a hash
: %foo = {'by' => 1, 'from' => 2};
: Would
: splurt :%foo;
: have the same result as
: splurt :by(1) :from(2);
:
: or would I need the braces in this case?
Hmm, I don't know where to begin. First, the braces are really
only intended for anonymous closures, not anonymous hashes. (Though
an argument could be made to allow that usage, which presumably
would map all the internal hash keys to parameter values.)
Next, colon is not a prefix operator, so you can't just put it
in front of %foo like that. Even if you allow for a "null" name,
we don't have adverbs that look like :abc%foo, so :%foo doesn't make
any sense. Plus you're passing it where a term is expected, so it's
not an adverb in any case unless you said
splurt() :%foo
or some such. But if you're gonna pass it where a term is expected,
it's just a list of pairs, and you could say
splurt %foo.pairs
or maybe even just
splurt %foo
presuming the signature of splurt won't confuse that for a scalar
argument. You can do tricks like that because normal argument
processing is pretty sophisticated. Adverbs, on the other hand,
are intended only for introducing single pairs, and extending the
syntax for them indefinitely would be a mistake of the same sort as
allowing people to nest statement modifiers. If you want to get
fancy with named parameters, put 'em in the argument list where
they belong.
That being said, I still wonder whether there ought to be a way
of pattern matching single hash arguments like we do single array
arguments. That is, we already have things like:
sub headtail ([$head, [EMAIL PROTECTED], $num) {...}
which will pattern match a call like
headtail(@array, 1)
so maybe there's some call for
sub headstails ({+$heads, +$tails, *%edges}, $num) {...}
that will pattern match a call like
headstails(%hash, 1);
On the other hand, we don't have a way to name such a parameter
in either the [] or {} case yet, so it's hard enough to relate
it to named parameters, let alone anonymous named parameters...
Larry
