Hi Anthony,

I don't like the idea of "specially compiling things" at all here. It means
we change some fundamental assumptions about the way stuff gets compiled for
no really good reason.

About a context extension: This is certainly one way to deal with the issue
but for some reason I still feel hesitant. Since I'm not really sure what
exactly disturbs me here I'd like to get some feedback from other people in
this area.

Tim? John?

Cheers,
  - Andreas

> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org 
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On 
> Behalf Of Anthony Hannan
> Sent: Friday, June 27, 2003 4:43 PM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: RE: [ENH] ContextCleanup-ajh ( [cd][er][et][su] 
> extremely useful; unclear about ContextTag )
> 
> 
> Avi Bryant <avi at beta4.com> wrote:
> > 
> > On Thu, 26 Jun 2003, Anthony Hannan wrote:
> > 
> > > But I would still like to have working stack copies in 
> conjunction with
> > > possible other experiments like delegation.  What if we 
> used receiverMap
> > > to hold a record containing the ContextTag and other 
> slots as desired
> > > for delegation, JIT, etc.  Then we can have all at once instead of
> > > choosing.  The record would only be created on demand 
> (contextTags are
> > > only needed for signal contexts and block closure homes). 
>  And the extra
> > > indirection is still pretty cheap.  What do you think?
> > 
> > What was wrong with Andreas' suggestion that ContextTag be 
> a package that
> > could be loaded by those that need correct stack copying, 
> but not part of
> > the base enhancements?
> 
> Then you could never load more than one enhancement that uses 
> the receiverMap
> at the same time.  Adding a ContextExtension record allows us 
> to load as many
> as we want (or for a single enhancement to utilize more than 
> one slot).
> 
> >  Since AFAIK the only current user of Continuation
> > is Seaside, and it can make do without ContextTag, it seems 
> unfortunate to
> > restrict ourselves or take a performance hit (and isn't 
> BlockContext>>home
> > used quite frequently?) for a total of 0 users.
> 
> I don't think there is a performance hit.  Returning to a 
> block home also
> involves checking for ensure:/ifCurtailed: contexts in 
> between so I don't think
> the extra indirection will be significant in comparison.  
> Also returning blocks
> are actually quite infrequent.
> 
> > I very much appreciate the desire to make as much as possible work
> > correctly out of the box, but - you've done the work on 
> ContextTag and we
> > know it's there if we need it, now let's find a reason to 
> need it.  Until
> > then, it doesn't make sense to me to give up the receiverMap slot or
> > introduce any extra indirections.
> 
> All right, I just thought of another idea.  Since only 
> particular contexts
> (block homes, signal contexts, and #on:do: contexts) are 
> referenced by a
> contextTag, I can compile these specially so the contextTag 
> is held in the
> first temp instead of the receiverMap.  To make sure it is 
> not some other
> context that happened to store a random contextTag in its 
> first slot, the
> method will have to be marked as well.  But since we are out 
> of header bits,
> the code itself will be the marker.  Only contexts with 
> contextTags will start
> with the following code: pushThisContext, send: #contextTag, 
> storePop: 0.
> 
> Cheers,
> Anthony
> 
> 
> __________________________________
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month!
> http://sbc.yahoo.com
>