At Thu, 10 Dec 2009 12:07:32 +0000, Magnus Therning wrote:
As I understand it it all started with laziness. I don't know if laziness is impossible without purity
More or less. Haskell is a language where anything can be evaluated lazily by default. Unlike say Scheme, where if you want something to be evaluated lazily you have to be explicit about it, in Haskell it's the opposite - if you want something to be evaluated _strictly_ you have to be explicit about it. If you write an impure expression in Haskell (e.g. using unsafePerformIO) the side-effects of it might be executed once, twice, or never, depending on the Haskell implementation in use, the optimisation flags, or even other Haskell code in the system. And the side-effects might be executed at unpredictable times, in an unpredictable order, and only some of them might occur. Now, this might be fine for debugging purposes, where you want to see what is being done under the hood - but for most other side-effects, you really want them to occur in a more controllable way. Hence, to answer John's question, a lazy language _has_ to be pure (apart from the unsafe functions) because laziness (or, to be more technically correct, non-strict evaluation) is incompatible with good control of the side-effects arising from impure code. Both Clean and Haskell deal with side-effects by allowing the programmer to write imperative code in a pure way - in Haskell, by using monads or FRP, and in Clean by using world-passing and uniqueness types. Now, that answer probably suffices for a Haskell beginner. Of course eventually you realise time and space usage is a side-effect, and _that_ needs to be controlled as well... but despite this, I think my answer is basically right. However, that's not the _only_ reason why you might want purity. Even in a strict language, purity makes it easier to reason about code, because you don't have to consider the environment, only the parameters that are passed in. Of course, it gets more complicated with monads, because the Environment monad and the IO monad both give you implicit environments at the level of "running the monadic actions". But even then, it's supposed to be easier to reason about (once you get the hang of it), and I'd broadly agree with this. -- Robin