On Nov 27, 2007, at 11:41 PM, Tanaka Akira wrote:

> In article <6168A472-3688-4D85-AAE1-49A2F376B908 / fallingsnow.net>,
>  Evan Phoenix <evan / fallingsnow.net> writes:
>
>> Yes, it does. Almost every language says that the order that the
>> arguments are evaluated in is "undefined", so I simply had rubinius
>> evaluate them the way that was simplest.
>
> Several exceptions: Ruby, Python, Java.
> They specified evaluation order.

Well, in my own defense, I have no clue if it's specified in ruby or a  
side effect because there is no spec. Matz indicated that it's  
expected to be left to right, so I can assume thats as good as  
specified.


>
>
> Since the restriction of the evaluation order, I'm not sure
> that what optimizations are possible when retry is removed.

I don't see how argument evaluation order has anything to do with  
retry semantics. It still requires the ability to rewind and  
completely re-evaluate those args, regardless of the order.

>
>
> retry in block on 1.9 is not more dangerous than break in
> block because
>

The big question is that the behavior the user expects? Break in a  
block is easy in rubinius because how calling blocks is implemented.

> foo {
>  ...
>  retry
>  ...
> }
>
> can be rewritten as follows.
>
> retrying = true
> while retrying
>  retrying = false
>  foo {
>    ...
>    retrying = true
>    break
>    ...
>  }
> end
>
> break can emulate retry.

Yep, I've considered this for implementing retry. Again, it comes back  
to why do we need it? If the user wants this behavior, why not have  
them code it like that? the retry keyword in a block is a feature  
probably only 10 people have ever used and if you search for code  
which uses it, you'll find almost none (the only instance I know of is  
in drb). retry in a block is used much, much, much less often than  
File.exists?, yet File.exists? was removed from 1.9. If we're in the  
mode of cleaning up cruft, I believe this qualifies.

  - Evan

>
> -- 
> Tanaka Akira
>