[Haskell-cafe] Why?

[Luke Palmer]

On Thu, Dec 10, 2009 at 2:42 PM, Stephen Tetley
<stephen.tetley at gmail.com> wrote:
> C'mon Andrew - how about some facts, references?

Filling in :-)

> 2009/12/10 Andrew Coppin <andrewcoppin at btinternet.com>:
>
>
>> 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