From: "vidar.hokstad@..." <vidar.hokstad@...>
Date: 2006-02-07T22:58:23+09:00
Subject: Re: lazy evaluation?

Martin DeMello wrote:
> vidar.hokstad@gmail.com <vidar.hokstad@gmail.com> wrote:
> >
> > It's your assumption of where the "retry" restarts execution that's
> > wrong... Essentially the retry in "repeat" will restart execution right
> > before the call to repeat, not at the start of the "repeat" method,
> > thus evaluating the arguments again.
> >
> > You can see that by changing your code so that there's an observable
> > side effect of the reevaluation:
>
> This seems wrong to me, for precisely the reason you cite - it means
> that I can never do something like object.foo(ary.pop), without
> physically reading the source of #foo to see whether it calls retry
> anywhere.

Run the code I posted and see. Or see the reply with an example using
tracing posted about the same time as my reply. Or to take any example
using pop:

def repeat(cond)
  return if !cond
  yield
  retry
end

ary = [1,2,3,4,5]

repeat(ary.pop) do
  p ary.size
end

In any case, though, regardless of what method you call you would
presumably want to know what it does before you use it, whether by
reading the source or reading documentation, or relying on the method
to be sanely named.

I just don't see how this behaviour makes any difference in terms of
what surprises a badly documented and/or badly named method might have
in store for you. After all, nothing stops anyone from doing all kinds
of other completely unexpected things to your environment in some
innocent sounding method - "retry" doesn't exactly add a lot to their
arsenal, and it makes it a lot easier to create your own control
structures.

Vidar