Re: retry semantics changed

Chiming in again on this...

On Nov 23, 2007, at 2:53 PM, Yukihiro Matsumoto wrote:

> Hi,
>
> In message "Re: retry semantics changed"
>    on Sat, 24 Nov 2007 07:19:32 +0900, Dave Thomas  
> <[e-mail]> writes:
>
> |I'm thinking that allowing retry in a block still has the effect of
> |invoking the controlling method again, reevaluating its arguments.
> |This means that the issues of side effects are still present:
>
> I understand, but does side effect issue matter?  The primary reason
> of retry removal is performance.  By allowing method re-invocation,
> every method call requires context saving for possible retry in the
> method.  For retry in the blocks, context is saved anyway to implement
> break/next/redo etc.  Note that I am not opposing for dedicating retry
> for exception handling.  But we have make things clear before making
> incompatible change.

Not true! The context a block was saved in does not include enough  
information to perform block level retry. The reason for this is block  
retry requires the ability to re-evaluate the arguments and re-call  
the method which called the block. That information is not typically  
in a block saved context (it's certainly not in rubinius currently).

Block retry requires the ability to go all the way back to before  
arguments were put on the stack (in rubinius and yarv's case). Here's  
what I mean:

Say the code in question is "self.foo.bar(1, 2) { retry }"

In a pseudo-code stack machine, this looks like:

push 2
push 1
push some_block_object
push self
call foo 0
call bar 2


This bar is called with the arguments and the block object. Now, retry  
in the block requires that control return all the way to right before  
'push 2' and start over. Charles and I confirmed this a while ago. The  
control point is not in the saved context typically and is actually  
much harder to get to than ones for break/next/redo.

I again put my vote in to remove retry in all contexts expect for  
exception handling.
It's a very little used feature that almost no one understands.

  - Evan Phoenix



>
>
> 							matz.
>