[racket] iterative lazy space-safe or not?

> > I do not think I'll be willing to give up this semantics
> > of memorizing exceptional behavior.
> 
> I probably wouldn't mind giving it up, but the problems that it leads
> to tend to be much more significant in the lazy language.

What do you mean by "the problems that it leads
to tend to be much more significant in the lazy language"?
You have other concerns than the language semantics 
for memorizing exceptions?
 
> There are still cases where the naive version is applicable.  A recent
> example is Hari's purely functional data structure code -- he uses
> promises extensively, but in that context there's no need to worry
> about exceptions or deal with multiple values, and IIRC, he doesn't
> even need the benefits of composable promises.  So I made up a small
> naive implementation to be used instead of the usual promises, and the
> result was a significant boost.  

I can perfectly believe that there are situations where you want lazys
and other situations where you only need delays.
For me, I'd need delays for initializing recursive bindings,
but truely lazy algorithms benefit from lazys. 

Optimizing Java compilers perform exception analysis to optimize
non-exception-raising code. I guess you could do the same, if you like; no?

> The bottom line is that the cost should be there, 

Agreed.

> but there's still place for a simple and faster version.  

Agreed.

Keiko