| 1 | =head1 NAME |
|---|
| 2 | |
|---|
| 3 | Perl6::FAQ::Capture - Capture objects |
|---|
| 4 | |
|---|
| 5 | =head1 DESCRIPTION |
|---|
| 6 | |
|---|
| 7 | This FAQ answers questions about B<Capture> objects, as well as their uses in |
|---|
| 8 | bindings and function calls. |
|---|
| 9 | |
|---|
| 10 | =head2 What |
|---|
| 11 | |
|---|
| 12 | =head3 What happened to references? |
|---|
| 13 | |
|---|
| 14 | They have been superseded by Capture objects. |
|---|
| 15 | |
|---|
| 16 | =head3 What is a Capture? |
|---|
| 17 | |
|---|
| 18 | A Capture is an object representing arguments in a function call. |
|---|
| 19 | More generally, Capture objects express annotated nodes with children |
|---|
| 20 | such as capture groups returned by rules, XML DOM nodes, argument lists |
|---|
| 21 | and more. |
|---|
| 22 | |
|---|
| 23 | For example, the arguments in C<say("Hello", "World")> is a Capture |
|---|
| 24 | object denoted by C<\("Hello", "World")>. |
|---|
| 25 | |
|---|
| 26 | =head2 How |
|---|
| 27 | |
|---|
| 28 | =head3 Can I see what captures look like? Does \$x no longer work? |
|---|
| 29 | |
|---|
| 30 | Prefix C<\> is now the Capture constructor. These are all equivalent: |
|---|
| 31 | |
|---|
| 32 | my $xcap1 = \$x; |
|---|
| 33 | my $xcap2 = \($x); |
|---|
| 34 | my $xcap3 = \($x :); |
|---|
| 35 | |
|---|
| 36 | All three represent an argument list with a single invocant C<$x>, |
|---|
| 37 | and hence are all equivalent with each other: |
|---|
| 38 | |
|---|
| 39 | $xcap1 === $xcap2 === $xcap3; # true |
|---|
| 40 | |
|---|
| 41 | =head3 What about capturing multiple arguments? |
|---|
| 42 | |
|---|
| 43 | Here's how Captures look like deferred argument lists: |
|---|
| 44 | |
|---|
| 45 | sub make_car ( |
|---|
| 46 | Str $model, |
|---|
| 47 | Str $color? = "black", |
|---|
| 48 | Int $doors = 4 |
|---|
| 49 | ) { ... } |
|---|
| 50 | |
|---|
| 51 | # some positional, some named |
|---|
| 52 | my $car_cap = \("Model T", doors => 2); |
|---|
| 53 | |
|---|
| 54 | # passing the opaque Capture as actual function arguments |
|---|
| 55 | my $car = make_car(|$car_cap); |
|---|
| 56 | |
|---|
| 57 | # extracting a specific positional argument |
|---|
| 58 | say "The thing is $car_cap[0]"; # Model T |
|---|
| 59 | |
|---|
| 60 | # or by name |
|---|
| 61 | say "It has $car_cap<doors> doors" # 2 doors |
|---|
| 62 | |
|---|
| 63 | =head3 How do I extract all positional arguments or all named arguments? |
|---|
| 64 | |
|---|
| 65 | As you can see above, a Capture object holds both positional and named |
|---|
| 66 | parts. If you want to retrieve all positional parts, there are two ways: |
|---|
| 67 | |
|---|
| 68 | $cap[]; # postfix .[] |
|---|
| 69 | @$cap; # prefix @ |
|---|
| 70 | |
|---|
| 71 | Both forms flatten under list context, so they may be used |
|---|
| 72 | interchangeably. However, only the postfix C<.[]> form interpolates in |
|---|
| 73 | a string. |
|---|
| 74 | |
|---|
| 75 | Similarly, access to named arguments is available by treating the Capture |
|---|
| 76 | as a hash: |
|---|
| 77 | |
|---|
| 78 | $cap{}; # postfix .{} |
|---|
| 79 | %$cap; # prefix % |
|---|
| 80 | |
|---|
| 81 | Note that the positional parts do not include the invocant. |
|---|
| 82 | |
|---|
| 83 | =head3 What do you mean by "invocant"? |
|---|
| 84 | |
|---|
| 85 | When you call an object's method, the C<self> inside the method is set |
|---|
| 86 | to that object. These are all equivalent: |
|---|
| 87 | |
|---|
| 88 | $fh.say("Hi!"); |
|---|
| 89 | say $fh: "Hi!"; |
|---|
| 90 | say($fh: "Hi!"); |
|---|
| 91 | |
|---|
| 92 | Note that an argument list can have at most one invocant. You can |
|---|
| 93 | construct a Capture object with an invocant using the same syntax: |
|---|
| 94 | |
|---|
| 95 | my $cap = \($fh: "Hi!"); |
|---|
| 96 | |
|---|
| 97 | To get back the invocant from a Capture object, use the prefix "$" operator: |
|---|
| 98 | |
|---|
| 99 | my $fh = $$cap; |
|---|
| 100 | |
|---|
| 101 | So this Perl5ish equivalence still holds: |
|---|
| 102 | |
|---|
| 103 | $x === $(\$x); |
|---|
| 104 | |
|---|
| 105 | =head3 What about multi-dispatch? |
|---|
| 106 | |
|---|
| 107 | Multi-dispatch governs cases where multiple subroutines or methods share |
|---|
| 108 | the same name, relying on the arity and types of tie-breaking I<parameters> |
|---|
| 109 | in their parameter list (Signature): |
|---|
| 110 | |
|---|
| 111 | multi f ($x; $z) { say 'A' } |
|---|
| 112 | multi f (Int $x, Int $y; $z) { say 'B' } |
|---|
| 113 | multi f (Str $x, Str $y; $z) { say 'C' } |
|---|
| 114 | |
|---|
| 115 | f(1, 2); # goes to A |
|---|
| 116 | f(1, 2, 3); # goes to B |
|---|
| 117 | f('x', 'y', 'z'); # goes to C |
|---|
| 118 | |
|---|
| 119 | During multi-dispatch, a tie-breaking parameter may bind to the invocant |
|---|
| 120 | argument (e.g. for multi-methods), or one of the positional arguments. |
|---|
| 121 | |
|---|
| 122 | However, regardless of single- or multi- dispatch, the argument list (Capture) |
|---|
| 123 | can never have more than one invocant. Typically, the presence of an invocant |
|---|
| 124 | indicates a method-call (which may fall back to a subroutine-call); the lack of |
|---|
| 125 | invocant means a subroutine-call. |
|---|
| 126 | |
|---|
| 127 | 1.foo(2); # Int.foo with 1 as "self"; if not |
|---|
| 128 | # found, fallback to foo(1, 2) |
|---|
| 129 | foo(1: 2); # same as above |
|---|
| 130 | |
|---|
| 131 | bar(1, 2); # never looks at Int.bar; calls &bar |
|---|
| 132 | # in lexical/package scope |
|---|
| 133 | |
|---|
| 134 | Method/subroutine calls are determined by the presence of an invocant at the |
|---|
| 135 | calling site. Single/multi dispatch are determined by the presence of "multi" |
|---|
| 136 | in the declaration site. The two concepts are entirely orthogonal. |
|---|
| 137 | |
|---|
| 138 | =head3 What happens when a named argument is repeated? |
|---|
| 139 | |
|---|
| 140 | Let's look at some examples: |
|---|
| 141 | |
|---|
| 142 | sub make_car (Int $doors) { |
|---|
| 143 | say "My car has $doors doors"; |
|---|
| 144 | } |
|---|
| 145 | make_car( |
|---|
| 146 | doors => 2, doors => 4 |
|---|
| 147 | ); # 4 doors |
|---|
| 148 | |
|---|
| 149 | sub board_ark (@animal) { |
|---|
| 150 | say "@animal.elems() animals boarded the ark"; |
|---|
| 151 | } |
|---|
| 152 | board_ark( |
|---|
| 153 | animal => "moose", animal => "elephant" |
|---|
| 154 | ); # 2 animals |
|---|
| 155 | |
|---|
| 156 | A Capture object may hold named arguments that occur twice or more. |
|---|
| 157 | When it's bound to a variable in the Signature, if the sigil is C<@>, then |
|---|
| 158 | it expands to a list of all arguments (in the order they were specified). |
|---|
| 159 | |
|---|
| 160 | Otherwise (i.e. if it's bound to a scalar or a slurpy hash), the last |
|---|
| 161 | argument overrides the previous ones. |
|---|
| 162 | |
|---|
| 163 | =head3 What do |$x, |@x and |%x mean? |
|---|
| 164 | |
|---|
| 165 | The prefix C<|> operator casts objects into Captures, and merges them |
|---|
| 166 | t into the Capture currently being constructed (e.g. an argument list): |
|---|
| 167 | |
|---|
| 168 | my $cap = \(1, 2, x=>42); |
|---|
| 169 | f(|$cap); # f(1, 2, x=>42) |
|---|
| 170 | |
|---|
| 171 | Array, List, Hash and Pair objects cast into Capture objects in obvious |
|---|
| 172 | ways: |
|---|
| 173 | |
|---|
| 174 | my $a = [1, 2]; f(|@$a); # f(1, 2) |
|---|
| 175 | my $l = (1, 2); f(|@$l); # f(1, 2) |
|---|
| 176 | my $h = {x => 42}; f(|%$h); # f(x => 42) |
|---|
| 177 | my $p = (x => 42); f(|%$p); # f(x => 42) |
|---|
| 178 | |
|---|
| 179 | It also works with C<@> and C<%> variables: |
|---|
| 180 | |
|---|
| 181 | my @a = (1, 2); f(|@a); # f(1, 2) |
|---|
| 182 | my @a := [1, 2]; f(|@a); # f(1, 2) |
|---|
| 183 | my %h = (x => 42); f(|%a); # f(x => 42) |
|---|
| 184 | my %h := {x => 42}; f(|%h); # f(x => 42) |
|---|
| 185 | |
|---|
| 186 | |
|---|
| 187 | =head3 What does $x = \@y mean? |
|---|
| 188 | |
|---|
| 189 | The same as C<$x = (@y: )>. That is, a Capture of one array as invocant. |
|---|
| 190 | |
|---|
| 191 | Unlike in Perl 5, this means that you can get back the Array object with: |
|---|
| 192 | |
|---|
| 193 | my @y2 := $$x; # get back the invocant |
|---|
| 194 | |
|---|
| 195 | instead of: |
|---|
| 196 | |
|---|
| 197 | my @y2 := @$x; # WRONG: $x contains no positional parts |
|---|
| 198 | |
|---|
| 199 | Manipulating the original value via the $x capture is still possible: |
|---|
| 200 | |
|---|
| 201 | $$x.push("another element"); |
|---|
| 202 | |
|---|
| 203 | Note the need for the extra $ sigil, implying we are accessing the |
|---|
| 204 | captured invocant. C<@$x.push()> would mean an attempt to add an extra |
|---|
| 205 | positional argument into C<$x>; this would fail as all parts are immutable |
|---|
| 206 | in an Capture object. |
|---|
| 207 | |
|---|
| 208 | (Captures are immutable; their underlying data may not be.) |
|---|
| 209 | |
|---|
| 210 | =head3 So $x = @y does not mean $x = \@y anymore. Then, what does it mean? |
|---|
| 211 | |
|---|
| 212 | It means assigning C<$x> with the object bound to C<@y> (typically an |
|---|
| 213 | Array object). |
|---|
| 214 | |
|---|
| 215 | This does not create Capture objects; to get back C<@y>, C<@$x> would do. |
|---|
| 216 | |
|---|
| 217 | Also note that all these forms mean the same thing: |
|---|
| 218 | |
|---|
| 219 | @y; |
|---|
| 220 | @@y; |
|---|
| 221 | @@@y; |
|---|
| 222 | @y[]; |
|---|
| 223 | @y[][]; |
|---|
| 224 | @y[][][]; |
|---|
| 225 | |
|---|
| 226 | =head3 Does this mean I can't have something akin to a reference to a reference? |
|---|
| 227 | |
|---|
| 228 | You can, as a Capture can contain another capture object in its invocant |
|---|
| 229 | slot: |
|---|
| 230 | |
|---|
| 231 | my $x = \\3; |
|---|
| 232 | say $$$x; # same as "say 3" |
|---|
| 233 | |
|---|
| 234 | =head3 Can I create a "pass-through" function that captures all arguments? |
|---|
| 235 | |
|---|
| 236 | Yes, using the C<\$> signature: |
|---|
| 237 | |
|---|
| 238 | sub f (\$args) { g(|$args) } |
|---|
| 239 | f(1, 2, x => 42); # same as g(1, 2, x => 42) |
|---|
| 240 | |
|---|
| 241 | The C<$args> above becomes a Capture object. |
|---|
| 242 | |
|---|
| 243 | =head3 What about delegating a method? |
|---|
| 244 | |
|---|
| 245 | Perl 6 has a few other provisions for this (e.g., .wrap), but if you want |
|---|
| 246 | more control over invocation, you can take advantage of the default Signature |
|---|
| 247 | for methods, which puts all positionals in C<@_> and named arguments in C<%_>: |
|---|
| 248 | |
|---|
| 249 | method front_meth { |
|---|
| 250 | $!real_obj.back_meth( |<< @_, %_ ); |
|---|
| 251 | } |
|---|
| 252 | |
|---|
| 253 | You can also take the argument list as a Capture object, and merge it with |
|---|
| 254 | another method invocation: |
|---|
| 255 | |
|---|
| 256 | method front_meth (\$args) { |
|---|
| 257 | $!real_obj_A.back_meth( |$args ); |
|---|
| 258 | } |
|---|
| 259 | |
|---|
| 260 | This works because when there is already an invocant present, further |
|---|
| 261 | invocants in the constructing argument list will be ignored. |
|---|
| 262 | |
|---|
| 263 | =head3 How is @x = (1, 2, 3) different from @y := (1, 2, 3) ? |
|---|
| 264 | |
|---|
| 265 | The latter is an error. :-) |
|---|
| 266 | |
|---|
| 267 | The C<:=> operator binds its left hand side (a Signature object) to its |
|---|
| 268 | right hand side (a Capture object), so the latter form is akin to: |
|---|
| 269 | |
|---|
| 270 | sub foo (@y is rw) { ... } |
|---|
| 271 | foo(1, 2, 3); # FAIL: three arguments passed where one is expected |
|---|
| 272 | |
|---|
| 273 | However, these forms are valid: |
|---|
| 274 | |
|---|
| 275 | *@y := (1,2,3); # slurpy @ |
|---|
| 276 | @y := ((1,2,3):); # list as invocant |
|---|
| 277 | @y := ((1,2,3),); # list as first positional |
|---|
| 278 | @y := (y => (1,2,3)); # named binding |
|---|
| 279 | |
|---|
| 280 | But they are still different from the assignment form. |
|---|
| 281 | |
|---|
| 282 | =head3 How is @x = (1, 2, 3) different from *@y := (1, 2, 3), then? |
|---|
| 283 | |
|---|
| 284 | This means that while C<@y> holds the values 1, 2, and 3, you cannot |
|---|
| 285 | modify the container itself, so this won't work: |
|---|
| 286 | |
|---|
| 287 | @y.push(4); # FAIL: cannot find method: List.push |
|---|
| 288 | |
|---|
| 289 | On the other hand, because variables are initialized by their sigils, |
|---|
| 290 | so these two mean the same: |
|---|
| 291 | |
|---|
| 292 | my @x := []; # new Array object |
|---|
| 293 | my @x; # implicitly does the same thing |
|---|
| 294 | |
|---|
| 295 | so C<@x = (1, 2, 3)> would simply populate the previously allocated |
|---|
| 296 | Array object with new elements. |
|---|
| 297 | |
|---|
| 298 | =head3 Is there any difference between $x = (1, 2, 3) and @y = (1, 2, 3)? |
|---|
| 299 | |
|---|
| 300 | Yes. The right-hand side in both case is a single List object constructed |
|---|
| 301 | with the list-associative C<< infix:<,> >> operator, but it is flattened |
|---|
| 302 | in the second case, and its elements are put into the previously allocated |
|---|
| 303 | Array container bound to C<@y>: |
|---|
| 304 | |
|---|
| 305 | $x.push(0); # FAIL: cannot find method: List.push |
|---|
| 306 | @y.push(0); # works just fine |
|---|
| 307 | |
|---|
| 308 | =head3 Is there any difference between $x = [1, 2, 3] and @y = [1, 2, 3]? |
|---|
| 309 | |
|---|
| 310 | Yes. As in Perl 5, the Array constructor C<circumfix:[ ]> does not |
|---|
| 311 | flatten under list context, so C<@y> receives a List with one element |
|---|
| 312 | (an Array object), which then becomes C<@y[0]>: |
|---|
| 313 | |
|---|
| 314 | $x.elems; # 3 |
|---|
| 315 | @y.elems; # 1 |
|---|
| 316 | |
|---|
| 317 | The cases below are similar to Perl 5 as well: |
|---|
| 318 | |
|---|
| 319 | $x.push(0); # works - $x.elems becomes 4 |
|---|
| 320 | @y[0].push(0); # works - @y.elems remains 1 |
|---|
| 321 | @y.push(0); # works - @y.elems becomes 2 |
|---|
| 322 | |
|---|
| 323 | =head3 Is there any difference between $x := [1, 2, 3] and @y := [1, 2, 3]? |
|---|
| 324 | |
|---|
| 325 | For the usual method-based operations, they are pretty much interchangeable: |
|---|
| 326 | |
|---|
| 327 | $x.push(0); # works - $x.elems becomes 4 |
|---|
| 328 | @y.push(0); # works - @y.elems becomes 4 |
|---|
| 329 | |
|---|
| 330 | However, they differ when you try to assign something into them: |
|---|
| 331 | |
|---|
| 332 | $x = 42; # FAIL - Array doesn't handle scalar assignment |
|---|
| 333 | @y = 42; # works - @y.elems is now 1 |
|---|
| 334 | |
|---|
| 335 | Note that C<$x = 42> fails because the C<:=> in C<$x := [1, 2, 3]> |
|---|
| 336 | changes the underlying container of $x from a Scalar into an Array. |
|---|
| 337 | Compare this with the assignment case: |
|---|
| 338 | |
|---|
| 339 | $x = [1,2,3]; |
|---|
| 340 | $x = 42; # works just fine |
|---|
| 341 | |
|---|
| 342 | and also binding into an integer: |
|---|
| 343 | |
|---|
| 344 | $x := 41; |
|---|
| 345 | $x = 42; # FAIL - Int doesn't handle scalar assignment either |
|---|
| 346 | |
|---|
| 347 | =head3 So how do Captures work with Rules? |
|---|
| 348 | |
|---|
| 349 | In the context of rules, Captures are superclasses of Match. So in the example of: |
|---|
| 350 | |
|---|
| 351 | my $rv = ("x-y-z-moose" ~~ /(.)-(.)-(.)-<animal> :{ return give_birth(|$/) }) |
|---|
| 352 | |
|---|
| 353 | C<give_birth()> gets called with 'x', 'y', and 'z' as positional arguments, |
|---|
| 354 | and :animal<moose> as a named argument. C<give_birth()> can return a Moose object - |
|---|
| 355 | and C<$rv> is assigned a Capture object with the Moose object in its invocant slot. |
|---|
| 356 | C<$rv> has the same positional and named slots as the Moose object - and you can |
|---|
| 357 | retrieve the Moose back through C<$rv as Animal>. |
|---|
| 358 | |
|---|
| 359 | Nested captures in the rule then become nested Capture objects within positional |
|---|
| 360 | slots in $/, which allows them to be retrieved as arguments for additional functions. |
|---|
| 361 | And so you can bind annotated nodes of a tree to particular function calls, passing |
|---|
| 362 | the data straight in thanks to the equivalence of Captures returned by rules and |
|---|
| 363 | Captures used to invoke functions and methods. As such, Captures could be considered |
|---|
| 364 | a natural data type for XML nodes, and provide considerable power for parsing DOMs using |
|---|
| 365 | Rules, and providing native tree manipulations. |
|---|
| 366 | |
|---|
| 367 | |
|---|
| 368 | =head2 Why |
|---|
| 369 | |
|---|
| 370 | =head3 What prompted this change? Was there something innately lacking in refrences? |
|---|
| 371 | |
|---|
| 372 | [needs beefing up.] |
|---|
| 373 | |
|---|
| 374 | * references lose form and type |
|---|
| 375 | |
|---|
| 376 | * Capture also does most of what globs did, but in a safer and saner manner |
|---|
| 377 | |
|---|
| 378 | * the concept of Capture is applicable in match results |
|---|