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:
$object->method($a,@b,%c);
method $object: $a, @b, %c;
the arguments to "method" are represented internally by a Capture equivalent to:
\($object: $a, @b, %c)
But this is essentially a forward reference to S06 and S12.
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);
:(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?
Actually, I didn't lose you there, Audrey did (albeit after talking to me). :)
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":
sub foo (Num Dog|Cat $numdog, MySig \$a ($i,$j,$k,$mousestatus)) {
+...}
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:
foo($mynumdog, \(1, 2.7182818, 1.0i, :mice($ms))
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, $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.
A little higher,
@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?
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.
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. :)
| [reply]
[d/l]
[select] |
It sounds like most of my questions that are not wrong docs are forward references. It would be helpful if such forward references were marked and worked as links. In the feather copy I downloaded, many of the hrefs within a document don't even work!
I guess the docs are in need of a fresh pair of eyes, as I'm finding all the relics. I've seen other inconsistent terminology, such as "item context" which seems to be the norm in S03. S02 has it in a few places but uses the familiar "scalar context" mostly, and defines, "# Perl still has the three main contexts: void, scalar, and list."
—John
writing from a hotel lobby in 昆明
| [reply] |