# Laziness and parallelism

**URL:** <https://discourse.haskell.org/t/laziness-and-parallelism/12002>\
**Category:** Uncategorized\
**Created:** [May 4, 2025, 3:59am UTC](https://discourse.haskell.org/t/laziness-and-parallelism/12002 "2025-05-04T03:59:17Z")\
**Posts on this page:** 1\
**Showing post:** 2

<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:** [May 4, 2025, 4:49am UTC](https://discourse.haskell.org/t/laziness-and-parallelism/12002/2 "2025-05-04T04:49:56Z")

</div>

- I associate the term _“automatic”_ with Haskell’s memory management because there’s no direct way to _“decree”_ (in ordinary Haskell) that some particular expression _“shall”_ work without it.

- In contrast, laziness in Haskell can be _“modulated”_ (hence the term _non-strict semantics_) - I can use (ordinary Haskell) bang annotations on types:

That is why I chose the phrase _“lazy by default”_ for my initial post about parallelism - Haskell can be written _“lazily”_, but that’s rarely seen these days.

* * *

> Parallel Haskell is indeed here and it’s great (which makes Haskell worth recommending for commercial use […])

I believe one **LaurentRDC** would completely agree with you!

- [Hasura migrating to Rust? - #18 by LaurentRDC](https://discourse.haskell.org/t/hasura-migrating-to-rust/6620/18)

> [@](#):
>
> 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 some aren’t quite satisfied:

- [Compile with threaded RTS by default by ulysses4ever · Pull Request #240 · ghc-proposals/ghc-proposals · GitHub](https://github.com/ghc-proposals/ghc-proposals/pull/240)

- [#16126: Make -threaded the default · Issues · Glasgow Haskell Compiler / GHC · GitLab](https://gitlab.haskell.org/ghc/ghc/-/issues/16126)

- [Make GHC -threaded the default RTS](http://discourse.haskell.org/t/make-ghc-threaded-the-default-rts/4220)

Completing `#240` would then present an opportunity for (Glasgow) Haskell - since it already goes to the trouble of identifying suitable candidate expressions for speculative evaluation:

[2.7. Version 9.6.7 — Glasgow Haskell Compiler 9.6.7 User's Guide](https://downloads.haskell.org/ghc/9.6.7/docs/users_guide/9.6.7-notes.html#compiler)

> Added new flags `-fspec-eval` and `-fspec-eval-dictfun` to allow switching off speculative evaluation […].

a parallel version of GHC could (at least to begin with) just annotate some of those candidates with calls to `par`, possibly depending on how many tasks the hardware can support. Since multithreading would be enabled by default in GHC, so would this _elementary_ form of parallelism.

(…hrm: I thought this was a private topic.)

---

_[View the full topic](https://discourse.haskell.org/t/laziness-and-parallelism/12002)._