# Mutable Value Semantics Trend vs Immutability

**URL:** <https://discourse.haskell.org/t/mutable-value-semantics-trend-vs-immutability/7619>\
**Category:** Uncategorized\
**Created:** [September 19, 2023, 5:39am UTC](https://discourse.haskell.org/t/mutable-value-semantics-trend-vs-immutability/7619 "2023-09-19T05:39:01Z")\
**Posts on this page:** 1\
**Showing post:** 6

<div class="post-metadata">

**Author:** ![atravers](https://avatars.discourse-cdn.com/v4/letter/a/45deac/32.png) [@atravers](https://discourse.haskell.org/u/atravers)\
**Post date:** [September 19, 2023, 9:55am UTC](https://discourse.haskell.org/t/mutable-value-semantics-trend-vs-immutability/7619/6 "2023-09-19T09:55:41Z")

</div>

> [@Dato](#):
>
> When calling functions on variables, the compiler does things more intelligently and tracks the change of state of the variables being used, instead of being overly optimistic like Haskell where variables are supposed to be unchanged, thus purity has to be enforced, or being overly pessimistic like usual imperative languages where statically analyzing the states is deemed infeasible in general.

Haskell also has this _“hybrid”_ ability (to an extent) - by using the monadic `ST` type, a function can have an imperative implementation but without imposing an imperative interface on its callers, by using `runST`. Others have also mention more recent developments e.g. linear types.

* * *

> [@Dato](#):
>
> But in Haskell, the fundamentals of it seems to prevent such addition?

No. And in fact, your prior observation:

> [@](#):
>
> It is probably better, instead of saying we should ban mutation because it causes all sorts of problems, to say that we should communicate our intention as clearly as possible to the compiler, the caller, and the callee so that when I mutate or want to keep a reference to a value, they can be noticed, so that they can leverage their tools to optimize, verify and modularize.

…is a reasonable description of what usually happens in Haskell: [by using types](https://dl.acm.org/doi/pdf/10.1145/319838.319848), we can indeed _“communicate our intention as clearly as possible to the compiler, the caller, and the callee so that when I mutate or want to keep a reference to a value, they can be noticed, so that they can leverage their tools to optimize, verify and modularize.”_

But this approach just isn’t to everyone’s liking:

- 

> [@](#):
>
> (pages 12-13 of 22)
> 
> _HASKELL_ uses _monads_ for destructive updates and I/O; they add a restricted form of stateful computation to a pure language, retaining referential transparency[\*](https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.91.3579&rep=rep1&type=pdf). The disadvantage is that programs become more complicated. Also, if imperative elements of a given application were not taken into account during its design but turn out to be necessary later on, often major parts have to be redesigned or (at least) reimplemented, especially because types change significantly. […]
> 
> The _TRUTH_ team considers this point as one of the biggest drawbacks of the purely functional paradigm as followed by _HASKELL_.
> 
> [Functional programming languages for verification tools: A comparison of Standard ML and Haskell](https://homepages.inf.ed.ac.uk/perdita/haskml.pdf) (2005)

- 

> [@](#):
>
> A straightforward solution would be to stick to the imperative style by using variations of the state monad [[24]](https://www.altocumulus.org/Fudgets/fudgets-fpca93.html#ref-24). This suggests a simple way of using an existing imperative toolkit in a functional program. It is likely, though, that this will imply an imperative programming style throughout the program, so why then use a functional language at all?
> 
> [Fudgets - A Graphical User Interface in a Lazy Functional Language](https://www.altocumulus.org/Fudgets/fudgets-fpca93.html) (1993)

* * *

> [@Dato](#):
>
> […] this feels like a comeback for imperative programming.

…or as I described it [here](http://discourse.haskell.org/t/an-epic-future-for-spj/3573/9):

> […] the siren call of pervasive imperativity is still just as beguiling […]

…a recent case in point:

> [@Disowning an STRef](http://discourse.haskell.org/t/disowning-an-stref/6968):
>
> Had an idle thought this morning: Would it be safe to have a new primitive disownSTRef :: STRef s a -\> ST s (STRef s' a) ? Note that s' is completely unconstrained. In particular, it could be RealWorld, which would mean that you could now create an IORef at toplevel without unsafePerformIO, which would be nice. The idea is that any STRef s a must have been created within the invocation of runST that we’re now in, and so disowning the ref can’t interfere with other state in the outside world. …

Mutation: [it remains just as troublesome](https://www.progsbase.com/blog/global-variables-still-a-major-source-of-problems-in-it-projects), but we still can’t seem to get rid of it entirely! This _seems_ promising:

- 

> [@](#):
>
> (page 46 of 55)
> 
> […] mainstream languages are adopting more and more declarative constructs: comprehensions, iterators, database query expressions, first-class functions, and more besides. We expect this trend to continue, driven especially by the goad of parallelism, which punishes unrestricted effects cruelly.

- 

> [@](#):
>
> [LaurentRDC:](http://discourse.haskell.org/t/hasura-migrating-to-rust/6620/18)
> 
> 1. Parallel performance is unmatched, especially given that I put very little effort in it. We’ve been able to tackle problems at a scale we would never have touched before;

…but there doesn’t appear to be a great interest in making Haskell parallel by default (at least for now), which would help _greatly_ to show the advantages of keeping things immutable as much as possible. And so in the absence of progress towards eliminating mutability entirely, new _“not-as-imperative”_ languages have appeared, with each promising to simplify _“the great mutability divide”_ in one form or another…and here we all are.

---

_[View the full topic](https://discourse.haskell.org/t/mutable-value-semantics-trend-vs-immutability/7619)._