Re: [Haskell-cafe] Why?

On Thu, Dec 10, 2009 at 2:42 PM, Stephen Tetley wrote:

C'mon Andrew - how about some facts, references?

Filling in :-)

2009/12/10 Andrew Coppin :

...

1. Code optimisation becomes radically easier. The compiler can make very drastic alterations to your program, and not chance its meaning. (For that matter, the programmer can more easily chop the code around too...)

Which code optimizations?

As a very potent example: stream fusion. Here is a talk demonstrating how it works. http://unlines.wordpress.com/2009/10/22/talk-on-loop-fusion-in-haskell/

...

2a. Unecessary work can potentially be avoided. (E.g., instead of a function for getting the first solution to an equation and a seperate function to generate *all* the solutions, you can just write the latter and laziness gives you the former by magic.)

Didn't someone quote Heinrich Apfelmus in this list in the last week or so:

http://www.haskell.org/pipermail/haskell-cafe/2009-November/069756.html

"Well, it's highly unlikely that algorithms get faster by introducing laziness. I mean, lazy evaluation means to evaluate only those things that are really needed and any good algorithm will be formulated in a way such that the unnecessary things have already been stripped off."

That was me. I love that quote. The half that you omitted is another point on Andrew's list: "But laziness allows to simplify and compose algorithms. Sometimes, seemingly different algorithms turn out to be two sides of the same coin when formulated with lazy evaluation. Isn't it great that finding the k-th minimum is not only an adaption of quicksort but can readily be obtained from it by composing it with (!! k)?"

http://apfelmus.nfshost.com/quicksearch.html

...

2b. You can define brand new flow control constructs *inside* the language itself. (E.g., in Java, a "for" loop is a built-in language construct. In Haskell, "for" is a function in Control.Monad. Just a plain ordinary function that anybody could write.)

Psst, heard about Scheme & call/cc?

But, very importantly, purity allows you to *restrict* the flow constructs that client code has available. If you have continuations + mutable state you can do anything, but the more code can *do*, the less you *know* about it. For example, providing parser combinators as an applicative functor offers more power than a traditional parser generator, but not enough that we can no longer parse efficiently. Luke