Audrey Tang wrote:
> Hm, Perl 6 actually has two different ways of putting Capture to some
> Code object... Following yesterday's P6AST draft I'll call them Call and
> Apply respectively:
> moose($obj: 1, 2); # this is Call
> &moose.($obj: 1, 2); # this is Apply
> elk(named => 'arg'); # this is Call
> &elk.(named => 'arg'); # this is Apply
> The difference is whether the Code is an object (Apply), or a "message"
> name (Call). As the same argument list can be reused in both cases, it
> seems the "method" part is better left out from the abstraction. That
My understanding is that Capture objects are intended to superceed perl5
references. Synopsys 2 states:
| You may retrieve parts from a Capture object with a prefix sigil
| $args = \3; # same as "$args = \(3)"
| $$args; # same as "$args as Scalar" or "Scalar($args)"
| @$args; # same as '$args as Array" or "Array($args)"
| %$args; # same as '$args as Hash" or "Hash($args)"
| When cast into an array, you can access all the positional arguments;
| into a hash, all named arguments; into a scalar, its invocant.
I find myself wanting to add the obvious extra case to this list. Should
&$args; # 'fail' ? (runtime error, or compile time?)
I'd prefer it to do something more analagous to a perl5 coderef
dereference -- assuming that it is possible to create a reference to
code using a Capture.
Also, I'm a bit confused By the idea that the invocant is obtained by a
scalar dereference, because I know that arrays and hashes can be
invocants, too. E.g. @a.pop. So, If I do:
my $args = \(@a:);
my $b = $$args; # @a as a scalar
my @c = @$args; # empty list
my @d := $$args; # bound to @a
Is there any way that a deref can determine that the invocant stored in
the capture was placed there using the '@' sigil? Perhpas this leads to
the question of whether there is ever a reason for code to distinguish
between @ invocants and $ invocants. I'm guessing that the answer must