On 09/17/2012 03:56 PM, Russel Winder wrote:
On Mon, 2012-09-17 at 15:49 +0200, Timon Gehr wrote:
[…]
In effect, everything is a non-null reference to mutable, but as
mutation is constrained rather specifically, it is possible to reason
about the behaviour of Haskell programs on a higher level of
abstraction.
> let fib n = if n<2 then n else fib (n-1) + fib (n-2)
> let x = fib 30
> let y = x
> let z = x
> y
(delay)
832040
> z
(no delay)
832040
This is just an artefact of Haskell being a lazy language: x is only
evaluated on demand; the lack of delay is due to the fact the value is
already computed.
The runtime cannot know that the value has already been computed
without keeping state. Identity is important, if I had written
let y = fib 30
let z = fib 30
There would have been a delay two times.
Hopefully no-one actually uses that expression for calculating Fibonacci
series for real.
This worry actually demonstrates my point. Different representations of
the same value are not equivalent in practice.
Are you sure the references are to mutable?
An evaluated expression is not the same thing as a non-evaluated
expression. But the same name is used to refer to both in the example,
ergo the reference is to mutable.
I had understood Haskell to be a single assignment to immutable values language.
That is the abstraction it provides. Values do not change, but their
representations have to, because of the evaluation strategy.
