[Haskell-cafe] Lazy evaluation from "Why Functional programming matters"

[C K Kashyap]

> Hi,
> Let us try to rewrite the code in a more java-esque syntax:
> It translates to something like the below generic method. Correct?
> static <T> T function(IBoundsCheck<T> within, Delta<T> eps,  Iterator<T>
> iterator, T initValue){
>       T currVal = initVal;
>     while(iterator.hasNext()){
>         T nextVal = iterator.next();
>          if(within.verify(delta, eps, currVal, nextVal))
>                           return currVal;
>          currVal = nextVal
>    }
> }
>
> I have not tested it but I think this is a fair translation of the code.
>  (For instance, by using an appropriate implementation of IBoundsCheck, I
> will be able to implement the 'relativeSqrt' functionality of the example).
> But this IS still a lazy evaluation. By passing an iterator instead of a
> list as the third argument of the static method, I achieved 'laziness'.
> In the example, the laziness is in the way we are iterating over the
> sequence of values [a0,f(a0), f(f(a0)),...] and so on and not on when the
> runtime evaluates appropriate values.
> Just that having to write,
> (repeat (next N) a0)
> is (take 1000 (repeat 1)) times more intuitive and convenient than having to
> implement the Iterator for T or implementing a true-while loop.
>
I see ... I think I understand now.
hmmm ... I am little disappointed though - does that mean that "all
the laziness" cool stuffs can actually be done using
iterators(generators)?
As in, but for the inconvenient syntax, you can do it all in - say java?

-- 
Regards,
Kashyap