callCC and BC

Anthony Hannan ajh18 at cornell.edu
Mon Mar 18 05:17:23 UTC 2002


Avi Bryant <avi at beta4.com> wrote:
> Anthony,
> I would very much like to get my Seaside framework working on the BC
> image, which requires a functional #swapSender: and #callCC:.  I know
> #swapSender: is on your TODO list, but if you're not in danger of
> implementing it in the near future, perhaps you could give me some rough
> pointers as to what it would involve?  I'm assuming it is still feasible
> to implement continuations purely in the image, right?
> Any info you can give would be appreciated.

Hi Avi, I implemented #swapSender for you (attached).  I will include it
in the next version of BC.  For continuations you probably want to make
a copy of the process stack before resuming so it can be reused.  For
more on how the process stack is layed out see the class comments in
Kernel-Execution category.  But here is a synopsis:
	First of all, Process2 is the correct process class in BC.  The
original Process class is still in the BC image but it is not used. 
Likewise for MethodContext and CompiledMethod.  Secondly, instead of a
process having a chain of contexts it has a chain of CallStacks.  Each
callStack holds one or more contexts/frames.  Frame i in a stack is
called by frame i-1 in the same stack and the first frame in a stack is
called by the last frame in the previous stack in the chain.  Frames are
only "objectified" when referenced in Smalltalk (eg. thisContext), in
which case a MethodContext2 is created which refers to its frame on a
stack.  Blocks are not contexts, they are like regular objects that have
their own special method that gets activated upon #value... in a regular
method context frame.  A block's indexable fields holds temp values it
captured from its home context, meaning it no longer needs to hold on to
its home context.  It does, however, reference its home context if its
block method has a return (^); it only uses this for finding the right
frame in the stack to return to.
	That is basically it from a high-level point of view.  Please don't
hestitate to ask more questions as you proceed.  The Q & A will be
helpful for people on this list to understand the new BC design.
	By the way there is a bug I noticed in BC that you should be aware of:
You cannot step over a #halt in the debugger.  I haven't worked on it
yet.  If it gets in your way let me know and I will address it sooner
rather than later.

Cheers,
Anthony
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BCswapSender-ajh.1.cs
Type: application/octet-stream
Size: 2588 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20020318/62a123c3/BCswapSender-ajh.1.obj


More information about the Squeak-dev mailing list