On Friday 11 July 2008 20:59:05 Patrick R. Michaud wrote:
> You're _completely_ missing my point. If we follow my proposal
> to modify Parrot or code generation such that a capture operation
> is performed for closures at the beginning of every outer sub
> invocation, then by the time we get to an assign operation a
> closure would _already_ have its current context captured, so
> only a simple clone is needed (which is what assign normally
> does -- it makes a copy of whatever is being assigned).
Now I'm confused.
At the risk of either belaboring the point (or demonstrating my inability to
follow a discussion), I want to point out that there are two different types
of Closures: named and anonymous. You can call named Closures by, well, name
while you can only invoke anonymous Closures if you currently have them in
registers (or can get them somehow).
Obviously all Closures need valid captured contexts, but we have a big problem
when attempting to invoke a named Closure before attaching its captured
context. In Perl 5 terms, this is the relevant code:
{
my $x;
sub set_x { $x = shift }
sub get_x { return $x }
}
In my opinion, using the newclosure op is inappropriate here as Patrick
correctly mentions, because of the possibility that set_x() may be a multi
variant. (It's also inappropriate in design terms from my perspective
because attaching the captured context should occur at compile time, or at
the very least before any runtime.)
Again, apologies if this is obvious to everyone else.
> And again, under my proposal I've been saying (apparently
> ineffectively) that "autoclose" would be gone entirely, and
> invoking a Closure that hasn't already had its context captured
> (i.e, outer_ctx is NULL) will throw an exception. In other
> words, there's no chance that "autoclose takes over when the
> thing is called".
Can I +1 more than once? I want this.
-- c
