Dave Whipp wrote: > Daniel Ruoso wrote: >> Hmm... I think that takes the discussion to another level, and the >> question is: >> >> "what does a capture returns when coerced to a context it doesn't >> provide a value for?" > > I'd like to take one step further, and ask what it is that introduced > capture semantics in the first place. And I suggest that the answer should > be "the use of a signature" > > I'd also suggest that we get rid of the use of backslash as a > capture-creation operator (the signature of Capture::new can do that) and > instead re-task it as a "signature" creation operator.
I believe that we already have a signature creation operator, namely ":( @paramlist )". Note also that retasking '\' destroys the analogy that currently exists between perl 6 captures and perl 5 references. > If we do that, then I think we can reduce the discussion of the semantics of > multi-returns to the semantics of assignments: > > If the sub/method defines a return-signature then that is used (with > standard binding semantics), otherwise the result is semantically a flat > list. > > If the LHS is an assignment is a signature, then the rhs is matched to it: > > my (@a, %b) = 1,2,3, b => 4; ## everything in @a; %b empty > my \(@a, %b) = 1,2,3, b => 4; ## @a = 1,2,3; %b = (b=>4) Change that second line to: my :(*...@a, *%b) = 1, 2, 3, b => 4; @a and %b have to be slurpy so that you don't get a signature mismatch. There's also the matter of how a signature with an invocant would handle the assignment: my :($a: *...@b, *%c) = 1, 2, 3, b => 4; Either $a == 1 and @b == (2, 3) or $a == undef and @b == (1, 2, 3). Which one is it? Probably the latter. Regardless, the magic that makes this work would be the ability to assign a flat list of values to a signature. Is this wise? -- Jonathan "Dataweaver" Lang
