On Tue, Oct 5, 2010 at 9:19 PM, steffen
Don't be to disappointed. One can always kinda fake lazy evaluation using mutable cells. But not that elegantly. In the example given above, all being used is iterators as streams... this can also be expressed using lazy lists, true. But one big difference between e.g. lazy lists and iterators is, that lazy values are (operationally) replaced by their result wheres values generated from iterators and streams are not.
For example one can use Iterators and chain them together in Java, to achieve more or less the same space and runtime-efficiency found by Stream-fusion in haskell (the Java JIT can abstract loads away, once the iterators are build together). But If you need to access the iterator's values more then once, you have to either force the full iterator into a list or rerun/reevaluate the iterator every time you need a value.
Lazy lists are nice, but haskell's laziness is not about lazy lists only. For example lazy evaluation also matters when creating "elegant" Embedded DSLs... have you ever tried to build a more complex EDSL without laziness and macros?
Thanks Ertugrul for the nice primes example. Steffen, Thanks for the explanation. Is there some literature around other lazy entities from the imperative side. I'm currently trying to get my Makefile EDSL to work - not sure, if that could turn complex. My ultimate aim it to write an EDSL for x86 - as in, describe a micro-kernel in haskell, compiling and running which would generate C code ( not sure if it's even possible - but I am really hopeful). Could you send me a sample on how I could use the reader monad for my Makefile EDSL. Regards, Kashyap