[Haskell-cafe] Why?

[Andrew Coppin]

Stephen Tetley wrote:
> C'mon Andrew - how about some facts, references?
>   

Facts I can do. References? Not so much...

>> 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?
>   

In a pure language, substituting a function call with the corresponding 
RHS is guaranteed to not alter the program. Eliminating common 
subexpressions is guaranteed not to alter the meaning of the program. 
Something like stream fusion which replaces a data structure in memory 
with a loop in the program code is guaranteed not to alter the meaning 
of the program. Should I continue?

On the other hand, turn up the optimisation settings on a C compiler 
high enough and the program breaks. Somewhere the compiler elides a 
second call to a function which actually happens to have some 
side-effect that the compiler isn't aware of, and your stream is now one 
byte out of alignment, or whatever. Fiddling with optimisation settings 
in GHC may make your program slow to a crawl rather than go faster, but 
it *never* makes it segfault on startup.

> >From a different point of view, whole program compilation gives plenty
> of opportunity for re-ordering transformations / optimization - Stalin
> (now Stalinvlad) and MLton often generated the fastest code for their
> respective (strict, impure) languages Scheme and Standard ML.
>   

I didn't say it's impossible to optimise impure languages. I said it's 
much harder.

>> 2. Purity leads more or less directly to laziness, which has several
>> benefits:
>>     
>
> Other way round, no?
>   

A philosopher once asked: Do we gaze at the stars because we are human? 
Or are we human because we gaze at the stars? Pointless, really.

Is Haskell pure because it's lazy, and being impure in a lazy language 
would be a hellish nightmare? Or is it lazy because in a pure language, 
there's no reason to be strict?

>> 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."
>   

Writing an algorithm custom-optimised to every possible use-case is 
probably more efficient than using laziness. On the other hand, using 
laziness is probably radically less typing, and arguably not that much 
slower. (And then you can invoke the notion of the Sufficiently 
Sophisticated Compiler...)

>> 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?
>   

No. Should I have?

>> 2c. The algorithms for generating data, selecting data and processing data
>> can be seperated.
>>     
>
> Granted. But some people have gone quite some way in the strict world, e.g.:
>
> http://users.info.unicaen.fr/~karczma/arpap/FDPE05/f20-karczmarczuk.pdf
>
>
>   
>> 2d. Parallel computation. This turns out to be more tricky than you'd think,
>> but it's leaps and bounds easier than in most imperative languages.
>>     
>
> Plenty of lazy and strict, pure and impure languages in this survey:
> http://www.risc.uni-linz.ac.at/people/schreine/papers/pfpbib.ps.gz
>   

All of these seem to be of the form "you can do this in an impure 
language". I didn't say you can't. I said it's easier.

>> 3. It's much harder to accidentally screw things up by modifying a piece of
>> data from one part of the program which another part is still actually
>> using. (This is somewhat similar to how garbage collection makes it harder
>> to free data that's still in use.)
>>     
>
> In a pure language I'd like to think its impossible...
>   

Agreed. But - unless your program involves no I/O at all - you would be 
wrong... :-(

Haskell programs can and sometimes do involve mutable state internally 
as well. And in that case, it's up to you to not accidentally do 
something dumb.