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".

Reply via email to