Klaus D. Witzel writes:
 > Hi Bryce,
 > 
 > turning the suggested primitive behind BlockContext>>#apply:from:to: into  
 > a #primitiveValue is, after checking receiver and arguments, easy.
 > 
 > Problems come as soon as the block later sends, whereafter #commonReturn  
 > does no longer know anything about #primitiveApplyFromTo. This asks for  
 > something that stores such state, for example by making a  
 > MethodContext>>#apply:from:to:on: solution (with last argument the block).
 > 
 > I can imagine that Exupery encounters similar situations (i.e. native code  
 > does a full send for whatever reason). Is there something that can be  
 > learned (or, perhaps, even copied) from Exupery.

Exupery modifies commonReturn: and transferTo: amongst other methods 
to allow it's modified contexts to be re-entered from compiled code.

I suspect that implementing #apply:from:to:on: in Squeak is a mistake.
First because it'll make the code less clear. Second because it's
going to be very hard to do with the current VM and contexts,
VisualAge doesn't have context objects which would make this sort of
thing easier but also means that it can't support Seaside. Third
because I'd need to re-implement any such primitive in Exupery. Forth
because you'll need to implement the primitive in the debugger so you
can still single step through do:. Fifth because such a primitive will
be harder to understand than our current do: implementation. And
finally because the current implementation or even one using count:
could be fully optimised by using full method inlining and a decent
optimising compiler. Full method inlining will optimise much more than
just do: and friends.

Full method inlining would also allow us to stop inlining methods such
as ifNotNil: without any drop in speed. Either optimise a very general
case or optimise a specific case based on profiling. 

Bryce