Lazy Evaluation And Object Composition

I did a google search for "lazy evaluation composition" to gain a little bit more insight on the interplay of the two concepts. Suprisingly, within the top 3 hits I found this piece which is quite illuminating that I reproduce it here:

Why am I using the decorator pattern? A very important lesson of functional programming is that function composition (together with using list for intermediate results of a computation) is a very powerful way of reusing code and building programs from pieces. Object composition is a very useful technique in OOP, superior in many situations to inheritance; it also provides good support for building software from pieces. The decorator pattern is extremely important as it bridges these two meanings of composition: it is the simplest case of object composition, and it may also be seen as some sort of ``function composition'' operator. Objects that transform data can be viewed as functions (they map their input to their output). If an object of this kind is obtained by ``decorating'' another similar (or should I say ``compatible'') object, it's like composing the transformations performed by each object. Usually the decorating object is perforing its transformation on the output of the decorated object, so the effect is similar to that of a shell pipe (the un*x shell equivalent of function composition).

Another important lesson of functional programming is that building complete partial results can be a waste of resources, as the next function in the composition chain may need only a few first elements from the partial result list, so computing the rest of the list would be a waste of time. The solution to this problem is the so called ``lazy evaluation'': the partial results' elements aren't computed until they are actually needed (in fact, ``lazy'' in ``lazy evaluation'' means delaying ``evaluation'' as long as possible). This way one gains efficiency while retaining the clarity of the function composition way of specifying computations.

A step further in ``lazy evaluation'' can be taken if only a small section of the partial result is needed: that is, the program can afford to ``forget about'' the already processed elements (it is only interested in a ``current'' section of the partial result list). In this case there is a very handy and simple way of implementing ``lazy lists'' in an imperative language like Java: generators.

A generator is an object that, on request, provides a response-object. Normally, it returns a new respose every time a request is made. In the context of parsing, where it is important to see the look-ahead token, generators need to be a little more sophisticated than that (the ``current'' section of the partial result list can be longer than one item).

I had a similar line of thought in "6 Degrees of Iterator". It's nice to read pieces like this that further increase and enhance the conceptual connections between seemingly different things.

Well the reason why I'm looking into "lazy evaluation" is that first its a loose-coupling technique, second is that it decouples stucture and evaluation and this decoupling is the inverse of the encapsulation techniques employed in Object Oriented programming.

I'm beginning to suspect that encapsulation (or maybe eager evaluation) itself is hampering our ability to build compositional services in the context of the enterprise (of course anyone with half a brain in the Business Rules community would have told you the same!). Over time I hope to gain better clarity on this subject, unfortunately right now I'm aggravated, "where did I missplace that pi-calculus book?"