Am 22.12.2015 um 13:31 schrieb Oleg:
But do read the next paragraph and the rest of the paper, and other articles on the web site http://okmij.org/ftp/continuations/PPYield/index.html
I have to say I almost stopped reading at "worst in lazy evaluation: its incompatibility with effects". Incompatibility with side effects is a good thing, so that's not "worst", and there are frameworks for doing effects (most notably IO), so there goes "incompatibility".
Our conclusion is that the modularity benefit of lazy evaluation can be held without lazy evaluation, gaining the predictability of the space and time behavior.
I just skimmed the paper, so correct me if I'm wrong. It seems to show how one can transform a specific class of lazy functions into generators. This seems to miss the point of laziness. Having lazy evaluation means that when writing a function, you don't know (and don't care) how much of the returned data structure is ever explored, that's the caller's decision. This means you do not ever transform your code as a generator, because you don't need to. As I said, I didn't do more than a quick scan, and I might be in error thinking it's a transformation just for a specific class of lazy functions. More importantly, I might have missed some essential point about how this isn't really a transformation, or that one does not need to transform the code to get a transformer out. So... please correct the omissions :-) Regards, Jo