From: Brian Mitchell <binary42@...>
Date: 2007-11-24T23:40:04+09:00
Subject: Re: retry semantics changed

On Nov 24, 2007 8:13 AM, Charles Oliver Nutter <charles.nutter@sun.com> wrote:
> Wolfgang N��dasi-Donner wrote:
> > =>
> >
> > before 'Otto'
> > In 'a'
> > In 'b'
> > In 'c'
> > before 'Otto'
> > In 'a'
> > In 'b'
> > In 'c'
> >
> > ..., because the whole method chain is evaluated again. This combined
> > with the new possible syntax...
>
> The reason this happens is because retry triggers both the receiver and
> the arguments to be reevaluated. In eval.c parlance, it causes the retry
> event to bubble all the way out to the iter node (the block-holding AST
> node that surrounds block-receiving calls) and then starts evaluation
> again, resulting in the whole call being revisited.
>
> So if the receiver is reevaluated, and the receiver is a call on another
> call on another call...they all get reevaluated. Same goes for the
> arguments.

Right. I think the only good way to handle that is to actually handle
it rather than invent an ugly way to abuse something like retry over
iteration expressions. If there is a concern on losing the ability to
build natural looking flow control methods, then maybe we should be
talking about alternative options.

Otherwise, it seems that most already agree that retry (outside of
begin-end) is quite a cumbersome operation for both implementors and
developers. Are we continuing the debate to remove the block form from
1.9 or are we trying for something else? I am curious to know what
course of action people would like to be taken here.

Brian.