Well, I had the right idea, but at a key moment I zigged when
I should have zagged.  So let's try this again.

----------------------------------------------------------------

On Wed, Nov 23, 2005 at 10:49:18PM +0100, Leopold Toetsch wrote:
> outer_sub - (the static sub PMC info) can't refer to :outer because the 
> :outer can be a closure too.  There are many incarnations of the :outer 
> then. Therefore the implementation needs sub->ctx (currently and IMHO).

The docs accidentally conflate non-closure Subs and closure Subs.  So
I'm going to write my way through this.  I think the design as is can
work, with each Sub having a static outer_sub attribute, but only if
closures also have an attribute that points to the Sub that they were
created from.

(Perl 5 calls this closure-creation process "cloning".  I'll adopt
that term for this doc, and maybe permanently.)

OK, here goes.  Correct me where I go wrong:

 * The initial static result of compilation is N Parrot_subroutines
   (Subs).

 * Each of these Subs may have a non-NULL outer_sub attribute, which
   describes the textual relationship of the Subs in the original
   source code.  For example, given:

      sub foo {
         my sub bar {
            my sub baz {
            }
         }
      }

   baz.outer_sub is bar, and bar.outer_sub is foo.

 * This is a static description of a static situation (the source code
   doesn't evolve at runtime).  So it need never change.

 * The result of newclosure is a new Sub, but I'm going to call it a
   Closure for clarity in this message.

 * Each Closure has an "outer_ctx" attribute, which points to the
   call frame in which it was cloned.  That call frame contains a
   pointer to the Sub (or Closure) that cloned the leaf Closure.

 * Therefore, we have outer_sub for the relationship of non-Closure
   Subs, and caller_ctx for Closure (cloning) relationships.

 * And thus there should be no need to modify a Sub after compilation,
   nor a Closure after cloning.

Does this describe the current situation and its features?
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Reply via email to