Re: retry semantics changed

On Nov 23, 2007 12:28 PM, Dave Thomas <[e-mail]> wrote:
> Removing it because of the potential side effects seems somewhat
> brutal. But, if we are going to remove this case, then I'd vote to
> remove its use in blocks altogether, and leave it just for exceptions.

You probably right but I am betting the biggest reason it was removed
was implementation based rather than language based. I can't say I
usually vote features down because they are dangerous (I like
TIMTOWTDI), but this one looks like more of a defect than a feature.

I can kind of see where this problem can stem from, consider this code
that has to delegate the call by passing parameters indirectly. In
that case you have to re-evaluate the delegator as well as the
original calling context's arguments. So the limitations are hard to
work with in many cases.

A possible way to get around this would be to introduce some crazy
sort of lazy argument declaration. This is how Io handles its flow
controlling primitives. For example, here is code for a while loop in
Io:

Object doUntil := method(
  loop(if(call evalArgAt(0), break, call evalArgAt(1)))
)

This code defines a method which implicitly leaves all the arguments
lazy. I can then evaluate or reflect upon the arguments at will using
the call object.

Now in Ruby this could (to be taken loosely) look something like:

class Object
  def do_until(~cond)
    loop {cond.call ? break : yield}
  end

  def proxy_until(~cond)
    do_until(~cond)
  end
end

Creating some sort of Proc-like object out of the argument allows the
same sort of capability. Now the big problem is that this would be
hard to use in variadic captures (unless the method context was first
class and supported something like ~*args). Of course, this creates
other problems with implementing simple and fast dispatch I am sure..
I guess I'd have to look into it more, which is also why I haven't
RCR'ed such a feature at this point in time.

Brian.