S02 states, "When cast into an array, you can access all the positional arguments; into a hash, all named arguments; into a scalar, its invocant." What is the "invocant" of a Capture object?Captures are designed to take a snapshot of any kind of call into any function or method, so when you call either of:
the arguments to "method" are represented internally by a Capture equivalent to:$object->method($a,@b,%c); method $object: $a, @b, %c;
But this is essentially a forward reference to S06 and S12.\($object: $a, @b, %c)
A short while later, "...When applied to a Capture argument of form \$x, the signature allows you to specify the types of parameters that would otherwise be untyped" and gives the example
my ::MySig ::= :(Int, Num, Complex, Status :mice);Actually, I didn't lose you there, Audrey did (albeit after talking to me). :)
:(Num Dog|Cat $numdog, MySig \$a ($i,$j,$k,$mousestatus));You lost me there. What is the purpose of $a? Is $a being captured or declared? What are the ramifications of having $i, $j, $k, and $mousestatus inside another set of parens? How would you "pass" values to this Signature containing a nested signature?
The purpose of $a is supposedly to bind an incoming Capture argument to the variable, but only if it also binds successfully to both MySig (defined earlier), and to the following sub-signature containing more real variable names. One problem with this example is that it's not really declaring any variable names since it is embedded in a larger undeclared signature. Another conflict is that the types of the two subsignatures are actually incompatible. If it had been the declared signature of an actual subroutine, say "foo":
then it would attempt to bind all those variables as real parameter variables within the sub. But due to the conflict, if you called it as:sub foo (Num Dog|Cat $numdog, MySig \$a ($i,$j,$k,$mousestatus)) { +...}
it would bind to MySig because MySig requires a named parameter for a mousestatus, but would not bind to $mousestatus because that is required to be positional. Contrariwise, if you called it as:foo($mynumdog, \(1, 2.7182818, 1.0i, :mice($ms))
it would be the other way around, and fail to bind successful to MySig. So it's basically a bad example. (I'm also not entirely sure a backslash is needed there in the signature at all. Seems like a plain $a parameter would bind to subsignatures the same way already.) You get a doggie biscuit for finding a bad example.foo($mynumdog, \(1, 2.7182818, 1.0i, $ms)
A little higher,Yes, + is a scalar operator, so it naturally imposes scalar context in addition to conversion to numeric. As for how it affects g(), well, it used to do that, but it doesn't anymore, because of the very fact that it has to reach outward like that. Now only a simple scalar variable on the left sets up scalar assignment, and all else is parsed as list assignment. So you have a right to be confused here, and get another doggie biscuit for finding a documentation fossil.@x[f()] = g(); # list context for f() and g() @x[f()] = +g(); # list context for f(), scalar context for g() @x[+f()] = g(); # scalar context for f() and g()The prefix operator + will not just convert its argument to a number, but impose scalar context on its argument as well? Even so, how does its use in the third line affect g()? The result of +f() is a number, but in the other lines, what if f() returned a number anyway, even when called in list context? Does + somehow reach outward, rather than just inward?
A little farther on, what is the difference between &foo($arg1, $arg2) and &foo.($arg1, $arg2), and are either specific to using the explicit & sigil rather than leaving it off? Much earlier, I recall the dotted form being used with a "long dot" to allow extra space. But now with the more general "unspace", is a dotted form still necessary? E.g. foo\ (42) vs foo\ .(42)?The dot on postcircumfix:<()> is always optional, as it is on all postfix operators (at least, those that are not method calls). In the case of a direct use of &foo in a call, the & is entirely redundant; it's just making the reference/dereference explicitly rather than implicitly.
Meanwhile, In S02, statment_control:if is mentioned as a "multiply-dispatched grammatical rule". What is that?Well, another forward reference, this time to S05, but essentially, when a regex tries to match <statement_control> (the short name), it finds all rules that start out with the short name and call the one that works best. (Which this one does, if the parser happens to be before an if statement.)
Ordinarily I would redirect such detailed questions to the perl6-languages mailing list, but I understand you have constraints on your access. Have as many doggie biscuits as you like. :)
In reply to Re: [Perl 6 S02] Capture and Signature Basics
by TimToady
in thread [Perl 6 S02] Capture and Signature Basics
by John M. Dlugosz
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |