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 > allows:
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 | operator: | | $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 it read: &$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 be "no".
