Aaron Sherman wrote:
IMHO most of the confusion here goes away if capture variables ONLY
store parameter-list-like captures, and any other kind of capture
should, IMHO, permute itself into such a structure if you try to store
it into one. That way, their use is carefully constrained to the places
where Perl 6 can't already do the job.
My understanding is that perl6 treats references as subsets of the
capture object - something along the lines of the following (WARNING -
this is going to border on 'internals' territory):
When you bind a variable to an object, that variable becomes a synonym
of that object for all purposes. However, barring auto-capturing, the
variable's sigil must match the object's type: bind a scalar variable
to an object, and the object better know how to behave like a scalar,
else you have trouble. I understood that list-like objects generally
don't know how to behave like scalars, and vice versa.
A capture object is an object that's intended to allow for
indirection: it's a perl6opaque object with (at least) three
attributes inside, all of which are to be used exclusively for binding
purposes: in effect, it's something like:
role Capture {
has $invocant, @positional, %named, ::returnType;
}
Note that you don't need any & or | attributes in order to capture a
parameter list.
The '\' prefix operator constructs a Capture object and binds the
various parts of its parameter list to the appropriate attributes.
The '$' prefix operator returns the Capture object's $invocant
attribute; the '@' prefix operator returns the Capture object's
@positional attribute; the Capture object's '%' prefix operator
returns the Capture object's %named attribute; and the Capture
object's '::' prefix operator returns the Capture object's
::returnType attribute.
Such a Capture object would be unable to capture codeblocks or other
Capture objects without extending its capabilities. That is, '\&code'
wouldn't have an attribute to bind to &code. There _might_ be a way
around this without introducing a new attribute, but only if code
objects know how to behave like scalars.
I may be off in terms of some of the details; but am I on the right
course in general?
--
Jonathan "Dataweaver" Lang
