Larry Wall wrote:
On Wed, Sep 20, 2006 at 11:18:09AM -0400, Aaron Sherman wrote:
: Trey Harris wrote:
: >Might I propose the following normalization:
: >
: >1. .call, method definition call(), and .wrap call all take captures.
:
: >2. .call() and both types of call() all pass on the arguments of the
: > current subroutine.
:
: > 3. To call with no arguments, use .call(\()) and call(\()).
:
: I have no problem with that, but the original form should probably exist
: too. I don't know if that's called invoke or what, but something that
: takes an arglist and constructs the capture to pass on would be very
: helpful to most users.
It would be suboptimal to give something so related a name that is
completely unrelated. If we had such a thing it should "callv" or
"callargs" or some such. But it's not yet clear to me that this is
frequent enough to deserve the sugar over call(\(...)).
invoke is just a very commonly used name in places like parrot and XS,
so I thought of it right off the bat.
I think your call, callargs and callcap are fine looking things.
As for $?ARGS, you're right, I was forgetting that it's not compile-time
constant.
Would $?ROUTINE have access to its current invocation? In other words,
could $?ROUTINE.args or $?ROUTINE.invocation.args find the current
invocation and ask for its capture? Why do I ask for that when you've
already said that signatures could include a capture? Macros. A macro
might want to do something with its caller's arguments, but doesn't know
what localized name it will have been given. If it can ask for its
$?ROUTINE, then it's always going to work.
macro debug() {
if $*ENV<DEBUG> {
q:code{
say("DEBUG: ", $?ROUTINE.name,
" called with: ",
Dumper($?ROUTINE.args))
};
} else {
q:code{1};
}
}
What we really need is a unary operator that is sugar for [,](=(...)). Just
don't anyone suggest *. :-)
I was thinking about that. I wonder if [\] would make sense, or is that
just begging to have in-editor parsers fall over screaming ;)
Other options might be (in decreasing order of my fondness for them):
callargs(<-- $foo) -- a nice inverse to ->
callargs($\ $foo) -- mnemonic: Dereference this capture
callargs(.* $foo) -- Ok, only to be passive-aggressive ;)
callargs(*\ $foo) -- kind of the same idea as $\
Candidates:
callargs(`$foo)
callargs(_$foo)
callargs(|$foo)
callargs(¢$foo)
None of these LOOK like capture-expansion to me other than _ which I'm
always hesitant to mess with. | seems too confusing.
Another approach would be to give captures a sigil that autoinserts, and
you'd have to \ it to suppress that, much like @foo always interpolates
into list context. Then we just get something like
callargs(¢x)
and the mixed declaration above would be
sub foo (¢args $a, $b, $c)
I've been a Perl programmer for 15 years, so I don't know why adding a
sigil would bother me, but it does... Can't give you a good reason,
though, so perhaps it's moot. Unicode sigils might have a valid ickiness
factor, though. I can't figure out what the ascii form of ¢ would be...
Certainly most expansions involving c and/or | are going to have
ambiguity problems.
