
Thoughts on Immutability in D - fogus
http://poita.org/index.php/blog/1-latest-news/67-thoughts-on-immutability-in-d
======
Peaker
That's at least one good reason for Haskell to have built-in laziness. The
_implementation_ of laziness uses side-effects. The _interface_ it exposes is
pure/immutable. If you had to implement it yourself, out of effectful
primitives, the result would have an effectful type, despite being pure. So it
is simply exposed as a pure primitive, despite being implemented via effects
under the hood. Pretty much all of the pure operations (e.g: add) boil down to
impure/effectful operations deep down (e.g: an ADD instruction mutating a
register).

That's why it is important to have an escape hatch -- capable of saying: "This
is a composition of effects, but I _know_ it is pure". In Haskell, this is
called unsafePerformIO, and it has the (impossible) type:

    
    
      unsafePerformIO :: IO a -> a
    

If you use this on a non-pure composition of effects, you get a bug.

~~~
Poita_
The implementation of _everything_ uses side-effects :-) A computer is nothing
more than a state machine after all.

You are right though. It's nice to have escape hatches. D allows this through
cast, but unfortunately casting away const causes undefined behaviour.

------
nickpp
Yeah, I really miss the mutable pattern for lazy instantiation too..

