Capture Literals

[Jonathan Lang]

How would I construct a capture literal that has both an invocant and
at least one positional argument? How do I distinguish this from a
capture literal that has no invocant and at least two positional
arguments?

Gut instinct: if the first parameter in a list is delimited from the
rest using a colon instead of a comma, treat it as the invocant;
otherwise, treat it as the first positional argument.

This would mean that the rules for capturing are as follows:

* Capturing something in scalar context: If it is a pair, it is
captured as a named argument; otherwise, it is captured as the
invocant.

* Capturing something in list context: Pairs are captured as named
arguments; the first non-pair is captured as the invocant if it is
followed by a colon, but as a positional argument otherwise; all other
non-pairs are captured as positional arguments.

So:

$x = /$a; # $$x eqv $a
$x = /:foo; # %$x eqv { foo => 1 }
$x = /($a,); # @$x eqv ( $a ); is the comma neccessary, or are the
() enough?
$x = /($a:); # $$x eqv $a
$x = /(:foo); # %$x eqv { foo => 1 }; assuming that adverbs can go
inside ().
$x = /($a, $b) # @$x eqv ($a, $b)
$x = /($a: $b) # $$x eqv $a; @$x eqv ($b)
$x = /:foo ($a: $b, $c):bar<baz> <== $d, $e <== flag => 0; # results
on next three lines:
# $$x eqv $a
# @$x eqv ($b, $c, $d, $e)
# %$x eqv { foo => 1, bar => 'baz', flag => 0 }

Note that this approach makes it impossible for a pair to end up
anywhere other than as a named argument in the capture object; while
this makes sense when the capture object is being used as a proxy
argument list, it makes less sense when it is being used as the
equivalent of perl 5's references, and thus is probably a bug.

--
Jonathan "Dataweaver" Lang

[Larry Wall]

On Thu, Sep 21, 2006 at 10:03:45PM -0700, Jonathan Lang wrote:
: How would I construct a capture literal that has both an invocant and

: at least one positional argument? How do I distinguish this from a
: capture literal that has no invocant and at least two positional
: arguments?
:
: Gut instinct: if the first parameter in a list is delimited from the
: rest using a colon instead of a comma, treat it as the invocant;
: otherwise, treat it as the first positional argument.

That is correct.

: This would mean that the rules for capturing are as follows:

:
: * Capturing something in scalar context: If it is a pair, it is
: captured as a named argument; otherwise, it is captured as the
: invocant.
:
: * Capturing something in list context: Pairs are captured as named
: arguments; the first non-pair is captured as the invocant if it is
: followed by a colon, but as a positional argument otherwise; all other
: non-pairs are captured as positional arguments.

Capture literals ignore their context like [...] does.

: So:
:
: $x = \$a; # $$x eqv $a
: $x = \:foo; # %$x eqv { foo => 1 }
: $x = \($a,); # @$x eqv ( $a ); is the comma neccessary, or are the
: () enough?

I think the () is probably enough.

: $x = \($a:); # $$x eqv $a
: $x = \(:foo); # %$x eqv { foo => 1 }; assuming that adverbs can go
: inside ().
: $x = \($a, $b) # @$x eqv ($a, $b)
: $x = \($a: $b) # $$x eqv $a; @$x eqv ($b)
: $x = \:foo ($a: $b, $c):bar<baz> <== $d, $e <== flag => 0; # results

: on next three lines:
: # $$x eqv $a
: # @$x eqv ($b, $c, $d, $e)
: # %$x eqv { foo => 1, bar => 'baz', flag => 0 }

Ignoring the syntax error, yes.

: Note that this approach makes it impossible for a pair to end up

: anywhere other than as a named argument in the capture object; while
: this makes sense when the capture object is being used as a proxy
: argument list, it makes less sense when it is being used as the
: equivalent of perl 5's references, and thus is probably a bug.

If you say "flag" => 0 it comes in as a pair rather than a named arg.

Larry

[Jonathan Lang]

Larry Wall wrote:
> : This would mean that the rules for capturing are as follows:
> :
> : * Capturing something in scalar context: If it is a pair, it is
> : captured as a named argument; otherwise, it is captured as the
> : invocant.
> :
> : * Capturing something in list context: Pairs are captured as named
> : arguments; the first non-pair is captured as the invocant if it is
> : followed by a colon, but as a positional argument otherwise; all other
> : non-pairs are captured as positional arguments.
>
> Capture literals ignore their context like [...] does.

What got me thinking about this was that I couldn't find decent
documentation about Capture literals in the synopses.

> : So:
> :
> : $x = \$a; # $$x eqv $a
> : $x = \:foo; # %$x eqv { foo => 1 }
> : $x = \($a,); # @$x eqv ( $a ); is the comma neccessary, or are the
> : () enough?
>
> I think the () is probably enough.

Problem: S02 explicitly states that '\3' is the same as '\(3)'. So:
both of them put 3 into the scalar slot of the capture object, or both
of them put the single-item list '(3)' into the array slot of the
capture object. Whichever way they go, how would you do the other?

> : $x = \($a:); # $$x eqv $a
> : $x = \(:foo); # %$x eqv { foo => 1 }; assuming that adverbs can go
> : inside ().
> : $x = \($a, $b) # @$x eqv ($a, $b)
> : $x = \($a: $b) # $$x eqv $a; @$x eqv ($b)
> : $x = \:foo ($a: $b, $c):bar<baz> <== $d, $e <== flag => 0; # results
> : on next three lines:
> : # $$x eqv $a
> : # @$x eqv ($b, $c, $d, $e)
> : # %$x eqv { foo => 1, bar => 'baz', flag => 0 }
>
> Ignoring the syntax error, yes.

Please don't ignore the syntax error; I'm not seeing it.

> : Note that this approach makes it impossible for a pair to end up
> : anywhere other than as a named argument in the capture object; while
> : this makes sense when the capture object is being used as a proxy
> : argument list, it makes less sense when it is being used as the
> : equivalent of perl 5's references, and thus is probably a bug.
>
> If you say "flag" => 0 it comes in as a pair rather than a named arg.

I was under the impression that the left side of '=>' still gets
auto-quoted in perl 6.

Anyway, you're saying that if I capture a pair, it will be stored in
the array portion of the capture object (the 'positional args'); if I
capture an adverb, it will be stored in the hash portion of the
capture object (the 'named args'). Right?

--
Jonathan "Dataweaver" Lang

[Austin Hastings]

Jonathan Lang wrote:
>
> What got me thinking about this was that I couldn't find decent
> documentation about Capture literals in the synopses.
>

Are Capture literals going to replace or unify the "assuming"/"currying"
behaviors?

=Austin