I'm gonna hop over to C# because that's where my favorite example lives: LINQ is a functional library that lets you describe queries on data that are executed lazily. The reason why the laziness is great in this scenario is that it lets you separate the tasks of constructing a data processing pipeline, and executing it.
The spot where it's tricky, though, is that it's a very leaky abstraction. It's easy to forget that these expressions might actually represent a lot of work, so if you get your lazy sequence object (IEnumerable<T> in C# terms) and then check if it has any values in one expression, and calculate its sum in another, then you might end up accidentally round-tripping a database twice.
Because of those sorts of stumbling blocks, I think laziness is a power that needs to be handled with care. I'm pretty sure that means you most certainly should not make it the default behavior.
"Why Functional Programming Matters" solved with C#
http://www.oki-osk.jp/esc/cs/whyfp.html
http://www.oki-osk.jp/esc/cs/whyfp2.html
http://www.oki-osk.jp/esc/cs/whyfp3.htmlExactly. I also wrote I am somewhat less enthusiastic about laziness.
So that leaves just one kind of glue as FP's contribution, which goes back to my point to the contribution being good but not sufficient.
Certainly true for composition but laziness is more the exception than the rule in today's FP languages. And it's getting an increasingly bad reputation to the point that even Haskell is slowly (and reluctantly) being dragged in the strict direction (which it will never fully reach because so much of it would break).