Hi Bryce,

earlier you wrote:

> Your shadow code will allow your implementation to run but it
> will slow down images when running on VMs without your primitive.

This is a good reason for objection, I agree.

On Sun, 17 Sep 2006 00:10:00 +0200, you wrote:
> Klaus D. Witzel writes:
>  > I hope we both are now tired enough from your comparision of Exupery  
> to
>  > the proposed primitiveApplyToFromTo.
>
> I am tired of this argument but I would appreciate it if you would
> try respond to my arguments.

I have neither the time nor the patience to go into your Exupery realm  
when "just" discussing the suggested primitiveApplyToFromTo. There is not  
that much experience with Exupery.

In particular, I'm not interested to discuss in this thread that Exupery  
won't support use of thisContext and peeking and poking of contexts.  
Clients for such objections are, for example
-  
http://www.shaffer-consulting.com/david/Seaside/dandelionOutput/Seaside-Continuations/Continuation.html
Don't misunderstand, I just do not want to discuss this particular  
objections of yours in this thread.

Another example, suddenly #class "should be a standard primitive not a  
bytecode". I do not want to discuss this in this thread. Even if it  
continues with
> so that people can override it [#class] if they wish.
> The VM change for class is tiny, just reimplement the bytecode to do
> a send then let that execute the primitive.
I do not want to argue for or against the performance loss of such a  
change, nor for or against
> [th]is your change makes the system more complex in a
> visible way to everybody

My last two examples of what I do not want to discuss in this thread are
> Also the common case [of existing #commonReturn] could be coded
> without the loops which risk branch mispredict when exiting.

and

> That cost is a language change.

-----------

Sorry for no better news :(

/Klaus