Re: retry semantics changed

Dave Thomas wrote:
> 
> On Nov 23, 2007, at 4:53 PM, Yukihiro Matsumoto wrote:
> 
>> 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.
> 
> 
> OK, I didn't understand the performance issues driving the decision.
> 
> The benefit of this change is that retry is now closer in user to redo, 
> next, etc...

I find retry-outside-rescue to be extremely dangerous. See the example I 
gave before:

(call_that_must_only_be_once).foo(another_similar_call)

With a definition of foo like the following:

def foo
   retry
end

The two methods-that-must-only-be-once would get repeatedly invoked, 
even though that was probably not the intention (and totally 
undetectable) by the caller. It's a really leaky feature, since it 
allows called code to break/alter the expected semantics of the caller. 
I don't want methods I call to be able to change the behavior of my 
method, especially when the "once" methods above could have dangerous 
side effects when called repeatedly.

The "cute" ability to implement a while loop with this code:

def my_while(cond)
   return unless cond
   yield
   retry
end

my_while(x < 1) { x += 1 }

...is in my opinion not worth the dangerous semantics of a keyword that 
can cause the receiver and arguments in the calling method to be 
reevaluated at any time.

The performance characteristics aren't really a concern for me.

- Charlie