# \[ANN\]\[RFC\] strict-mutable-base - strict variants of mutable data types from base

**URL:** <https://discourse.haskell.org/t/ann-rfc-strict-mutable-base-strict-variants-of-mutable-data-types-from-base/10266>\
**Category:** Announcements\
**Created:** [August 31, 2024, 3:51pm UTC](https://discourse.haskell.org/t/ann-rfc-strict-mutable-base-strict-variants-of-mutable-data-types-from-base/10266 "2024-08-31T15:51:53Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![arybczak](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/arybczak/32/2527_2.png) [@arybczak](https://discourse.haskell.org/u/arybczak)\
**Post date:** [August 31, 2024, 3:51pm UTC](https://discourse.haskell.org/t/ann-rfc-strict-mutable-base-strict-variants-of-mutable-data-types-from-base/10266/1 "2024-08-31T15:51:53Z")

</div>

I’m preparing to release a new small library https://github.com/arybczak/strict-mutable/tree/master/strict-mutable-base that implements API for strict (WHNF) variants of [Chan](https://github.com/arybczak/strict-mutable/blob/master/strict-mutable-base/src/Control/Concurrent/Chan/Strict.hs), [IORef](https://github.com/arybczak/strict-mutable/blob/master/strict-mutable-base/src/Data/IORef/Strict.hs) and [MVar](https://github.com/arybczak/strict-mutable/blob/master/strict-mutable-base/src/Control/Concurrent/MVar/Strict.hs) for proactive prevention of space leaks (links lead to the source code in the repo).

Basically, pretty much always when I need MVarS or IORefs in my code, I want strict modification, but

- for MVar there are no such functions, so you either always have to write a utility function or remember to use `$!` or similar every time you `modifyMVar`, which is annoying and way too fragile.
- for IORef there’s `modifyIORef'`, but again, it’s far too easy to forget the `'` and end up with a space leak manifesting itself later. `writeIORef` is also too lazy.

I wanted API that

1. Guarantees that the data you store in MVar/IORef is always in WHNF.
2. Has the simplest structure/deps possible.

Surprisingly there seems to be no package for this. The closest I found are

- [strict-concurrency](https://hackage.haskell.org/package/strict-concurrency), but it doesn’t use newtypes over base types (so no (1)) and requires `NFData`, which is IMO too strong. Also, judging from GH activity the package seems abandoned.
- [strict-mvar](https://hackage.haskell.org/package/strict-mvar) which is almost what I want, but it’s based on `io-classes` (and looks like it got deprecated recently) 😞

The plan is to release `strict-mutable-base`, perhaps add a wrapper package for `MonadUnliftIO`/`MonadBaseControl` and also `strict-mutable-stm` for corresponding types in the `stm` package, since I need strict variants of these too, just less often.

However, maybe I’m missing something and there already exists such a package and I’m just not aware of it, in such case please let me know. Same if you have any comments about the API, better to take care of potential issues before the first release.

---

<div class="post-metadata">

**Author:** ![amesgen](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/amesgen/32/2083_2.png) [@amesgen](https://discourse.haskell.org/u/amesgen)\
**Post date:** [September 1, 2024, 9:45am UTC](https://discourse.haskell.org/t/ann-rfc-strict-mutable-base-strict-variants-of-mutable-data-types-from-base/10266/2 "2024-09-01T09:45:14Z")

</div>

> [@arybczak](#):
>
> [strict-mvar](https://hackage.haskell.org/package/strict-mvar) which is almost what I want, but it’s based on `io-classes` (and looks like it got deprecated recently)

FTR: It was deprecated because it now is part of [`io-classes`](https://hackage.haskell.org/package/io-classes) as a public sublibrary.

---

<div class="post-metadata">

**Author:** ![ocramz](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/ocramz/32/3713_2.png) [@ocramz](https://discourse.haskell.org/u/ocramz)\
**Post date:** [September 2, 2024, 3:43am UTC](https://discourse.haskell.org/t/ann-rfc-strict-mutable-base-strict-variants-of-mutable-data-types-from-base/10266/3 "2024-09-02T03:43:01Z")

</div>

@arybczak This is great! Especially if it comes with an `unliftio` adapter.

Re. API design, I imagine it will take me some active practice to adopt it because of all the “primed” variants of the usual interfaces. Perhaps a typeclass based interface that lets you choose strict vs non-strict variants (like mtl does) according to which module you import would also make it easier to migrate. WDYT?

---

<div class="post-metadata">

**Author:** ![arybczak](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/arybczak/32/2527_2.png) [@arybczak](https://discourse.haskell.org/u/arybczak)\
**Post date:** [September 2, 2024, 5:30am UTC](https://discourse.haskell.org/t/ann-rfc-strict-mutable-base-strict-variants-of-mutable-data-types-from-base/10266/4 "2024-09-02T05:30:54Z")

</div>

If I dropped ticks from the API, I don’t think you need any typeclasses, you could just change the import of `Control.Concurrent.MVar` to `Control.Concurrent.MVar.Strict` etc. and that would be it.

I considered this design, but I chose to go with ticked variants because MVar/IORef/Chan is generally imported unqualified (unlike e.g. Text or Map) and then at use sites you can’t see whether operations are strict or lazy, which I find unsatisfactory.

With ticked API you can also use hlint in a CI to forbid usages of `modifyMVar` and `modifyIORef` for automated checking that lazy stuff doesn’t get through.

---

<div class="post-metadata">

**Author:** ![tomjaguarpaw](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/tomjaguarpaw/32/1230_2.png) [@tomjaguarpaw](https://discourse.haskell.org/u/tomjaguarpaw)\
**Post date:** [September 2, 2024, 9:45am UTC](https://discourse.haskell.org/t/ann-rfc-strict-mutable-base-strict-variants-of-mutable-data-types-from-base/10266/5 "2024-09-02T09:45:15Z")

</div>

I’m very much supportive of this idea. We need more strict variants of commonly-used functionality, so we can make invalid laziness unrepresentable.

---

<div class="post-metadata">

**Author:** ![arybczak](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/arybczak/32/2527_2.png) [@arybczak](https://discourse.haskell.org/u/arybczak)\
**Post date:** [September 2, 2024, 11:26am UTC](https://discourse.haskell.org/t/ann-rfc-strict-mutable-base-strict-variants-of-mutable-data-types-from-base/10266/6 "2024-09-02T11:26:07Z")

</div>

FYI, [it’s released](https://hackage.haskell.org/package/strict-mutable-base) 🙂

---

<div class="post-metadata">

**Author:** ![enobayram](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/enobayram/32/1815_2.png) [@enobayram](https://discourse.haskell.org/u/enobayram)\
**Post date:** [September 2, 2024, 11:59am UTC](https://discourse.haskell.org/t/ann-rfc-strict-mutable-base-strict-variants-of-mutable-data-types-from-base/10266/7 "2024-09-02T11:59:27Z")

</div>

Throughout my 7-year production Haskell experience working on web applications/services, all the space leaks I can remember were caused by a non-strict use of one of these types.

---

<div class="post-metadata">

**Author:** ![Kleidukos](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/kleidukos/32/1213_2.png) [@Kleidukos](https://discourse.haskell.org/u/Kleidukos)\
**Post date:** [September 2, 2024, 12:09pm UTC](https://discourse.haskell.org/t/ann-rfc-strict-mutable-base-strict-variants-of-mutable-data-types-from-base/10266/8 "2024-09-02T12:09:20Z")

</div>

Here’s to seven better years in production!

---

<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 2, 2024, 1:50pm UTC](https://discourse.haskell.org/t/ann-rfc-strict-mutable-base-strict-variants-of-mutable-data-types-from-base/10266/9 "2024-09-02T13:50:35Z")

</div>

Alternatively, the implementation of laziness GHC uses [could be upgraded](https://web.archive.org/web/20130610122750/https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.9.9901&rep=rep1&type=pdf), thereby ending this _“cottage industry”_ of strict duplicate types: so much **less** code to maintain…