References in D

[Timon Gehr]

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.