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(\(...)).
By the way, call() is just short for nextroutine().call() or some such,
where nextroutine() is a mystical call that retrieves the next candidate
based on what kind of dispatcher we're in.
: >4. Introduce some syntax for getting a capture of the current argument
: > list explicitly. Perhaps $?ARGS or $?_ or $?CAPTURE. One shouldn't
: > have to choose between repeating your 20 parameters in order to take a
: > capture of them, and eliminating your nice self-documenting 20
: > parameter names so you can use the easy \$arglist trick.
:
: I like the idea in 4, even though I'm not sure that I follow the rest of
: your logic. Having access to a variable that contains the current
: argument list called $?ARGS seems to be in line with the rest of the $?
: state variables that are provided.
Uh, no, $? variables are supposed to be compile-time constants. That's why
there's no $?SELF anymore.
Since individual constraints within the siglet are considered to be
"anded", it might be possible to declare both a capture and the rest of
the parameters like this::
sub foo (\$args $a, $b, $c)
In other words we relax the constraint that \$x has to come at the
end, so \$x would just take a snapshot of the rest of the args and
keep processing the binding to any remaining parameters.
: So, in general, I think the only thing missing is something like invoke
: so that:
:
: invoke(1,2,3);
:
: is identical to:
:
: call(\(1,2,3));
:
: and:
:
: invoke([,] =$?ARGS);
:
: is identical to:
:
: call($?ARGS);
:
: is identical to:
:
: call();
We might prefer a three-way distinction just to avoid user confusion:
call; no args allowed, always uses existing parameters
callcap($capture) one arg, must be capture (plus named?)
callargs($a: $b, $c) same as callcap(\($a: $b, $c));
(plus the corresponding dot forms). Alternately, just keep callargs and
force callcap to be written callargs([,] =$capture). After all, if you're
going to do anything with the args, you're usually not interested in the
whole original capture by itself.
What we really need is a unary operator that is sugar for [,](=(...)). Just
don't anyone suggest *. :-)
Candidates:
callargs(`$foo)
callargs(_$foo)
callargs(|$foo)
callargs(¢$foo)
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)
: Certainly a distinction on call vs call() is not what Perl 6 programmers
: will come to expect from the rest of the language, and I see no pressing
: reason to introduce it here.
Yes, that would be a mistake. Macros that abuse () are a design smell.
Larry
