On Thu, Jul 10, 2008 at 09:35:29PM -0400, Bob Rogers wrote:
> Hmm. I have been assuming that when you say "taking a closure", that is
> equivalent to "using *the* closure" for a given :outer context. It's
> beginning to dawn on me that this might not be what you mean; more
> below.
I think I'm not certain exactly what I mean here either. :-|
> But I don't think this is out of the ordinary. As an example of
> another nontrivial case of BEGIN-time processing, consider the following
> Perl 5 code:
>
> sub foo {
> print "This is the original foo.\n";
> }
>
> my $old_foo;
> BEGIN {
> $old_foo = \&foo;
> }
>
> sub foo {
> print "Out with the old, in with the new.\n";
> $old_foo->();
> }
>
> foo();
Perl 6 disallows having multiple subs of the same
name unless they are explicitly declared 'multi' or
the later subs provide the "is instead" trait [1].
Yes, handling 'is instead' may mean we need some
adjustments to the compiler -- but I think it's
more likely that we'll have Perl 6 namespace PMCs
that throw an exception when something attempts
to overwrite an existing sub using the normal
'add_sub' mechanisms.
> [...] However, if some
> or all of these references were "downward" (i.e. not referenced after
> the containing block returns), then the compiler need not implement
> those subs via closures. In Parrot, the two available technologies for
> doing this are inlining, and generating bsr/ret subroutines.
...but those technologies are available only if the nested closures
don't have any local lexicals of their own. If they do, then we still
need a separate .sub to be able to hold their lexicals.
Unfortunately, at this point in the discussion I don't feel I
understand enough about closures and lexicals to be able to
posit what S04 is really talking about, or to helpfully respond to
the points and questions you're raising--which I'm sure are good
ones. I think I need to take a break from this topic for
a while, because it's highly frustrating to me right now.
(None of what you're saying or doing is the source of that
frustration -- it's simply that I feel like I'm stumbling
and speaking blindly about a topic that isn't clear to me
yet and for which I seem to be unable to find any concrete
answers about this topic in either Parrot or Perl 6 that
will enable me to build a framework of understanding.)
> Since at least October 2006, and up through r28762, "autoclose" meant
> the ability of subs marked with :outer to turn into working closures
> without the benefit of "newclosure".
OK, this part I understand better now. Yes, I'm using autoclose, as
you describe it here.
> So you are definitely using "autoclose." In fact, your RT#56398
> ticket effectively asks to extend this feature so that it updates the
> outer_ctx on *every* call, which (as implemented) breaks newclosure.
If that's what I was effectively asking in RT #56398, it was *completely*
unintentional on my part. All I'm really wanting to know is what
PIR the compilers and tools should be emitting for these very
common Perl 6 constructs, and to have that PIR work in Parrot.
Trying to get simple nested blocks and subs containing lexical
variables to work in Rakudo and NQP has been and continues to be
a very frustrating trial-and-error exercise, and I just want
(pardon the pun) closure.
Thanks again for bearing with me on this, and my apologies for
not really being able to respond to the points you're raising.
Pm
