# Some Haskell idioms we like

**URL:** https://discourse.haskell.org/t/some-haskell-idioms-we-like/13528
**Category:** Links
**Created:** [January 14, 2026, 6:17am UTC](https://discourse.haskell.org/t/some-haskell-idioms-we-like/13528 "2026-01-14T06:17:51Z")
**Posts on this page:** 2
**Page:** 1

<div class="post-metadata">

### Author: ![jackdk](https://avatars.discourse-cdn.com/v4/letter/j/9f8e36/32.png) [@jackdk](https://discourse.haskell.org/u/jackdk)
#### Post date: [January 14, 2026, 6:17am UTC](https://discourse.haskell.org/t/some-haskell-idioms-we-like/13528/1 "2026-01-14T06:17:51Z")

</div>

> **[Some Haskell idioms we like](https://exploring-better-ways.bellroy.com/some-haskell-idioms-we-like.html)**
>
> Some of the idioms we've adopted to make our Haskell code clearer.

---

<div class="post-metadata">

### Author: ![danidiaz](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/danidiaz/32/92_2.png) [@danidiaz](https://discourse.haskell.org/u/danidiaz)
#### Post date: [January 14, 2026, 9:26pm UTC](https://discourse.haskell.org/t/some-haskell-idioms-we-like/13528/2 "2026-01-14T21:26:01Z")

</div>

Wholeheartedly agree with “design modules for qualified import”!

I wonder if one should opt for “flatter” module hiearchies and eschew the typical top-level modules like `Data` and `Control` in order to make the qualified import approach less noisy and less requiring of aliases.
