# Best way to create a typeclass dependency graph?

**URL:** <https://discourse.haskell.org/t/best-way-to-create-a-typeclass-dependency-graph/14666>\
**Category:** Learn\
**Created:** [September 8, 2026, 8:10pm UTC](https://discourse.haskell.org/t/best-way-to-create-a-typeclass-dependency-graph/14666 "2026-09-08T20:10:07Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![B-rando](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/b-rando/32/5746_2.png) [@B-rando](https://discourse.haskell.org/u/B-rando)\
**Post date:** [September 8, 2026, 8:10pm UTC](https://discourse.haskell.org/t/best-way-to-create-a-typeclass-dependency-graph/14666/1 "2026-09-08T20:10:07Z")

</div>

I was doing some refactors for a project I’m working on, and I found myself in a situation where it would be _really_ handy if I could get a graph of the project’s typeclass dependencies. Including cross-module dependencies.

I did a bit of hacking, and managed to get something working using a GHC plugin and Prolog. The GHC plugin outputs the constraint information for each module into a single Prolog file, and then my Prolog script queries that file to make a Graphviz file for the part of the graph I care about.

This works, but it’s pretty janky and won’t be good enough if we decide to add the tool to our CI. My gut instinct is that I should redo it using our HIE files, so that I can keep everything in Haskell and so that it can be run independently of GHC.

My question is, has anyone done something like this before? If there’s a tool I can reuse, or some thoughts on the best process, I’d appreciate a comment!

---

<div class="post-metadata">

**Author:** ![ozkutuk](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/ozkutuk/32/3992_2.png) [@ozkutuk](https://discourse.haskell.org/u/ozkutuk)\
**Post date:** [September 8, 2026, 9:03pm UTC](https://discourse.haskell.org/t/best-way-to-create-a-typeclass-dependency-graph/14666/2 "2026-09-08T21:03:02Z")

</div>

There is [Calligraphy](https://github.com/jonascarpay/calligraphy) which works exactly as you describe: it processes HIE files and passes it to Graphviz to produce a graph. I can’t remember if it can specifically process typeclass dependencies, but there are some filtering options available, worth checking out.

---

<div class="post-metadata">

**Author:** ![olf](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/olf/32/3813_2.png) [@olf](https://discourse.haskell.org/u/olf)\
**Post date:** [September 8, 2026, 9:05pm UTC](https://discourse.haskell.org/t/best-way-to-create-a-typeclass-dependency-graph/14666/3 "2026-09-08T21:05:39Z")

</div>

What exactly is a _type class dependency_ for you?  
Very likely anything in the type class definition, like  
`class Eq a => Ord a` would count as such a dependency.  
But what about instances? If your project defines classes `A` and `B` and concrete type `T :: * -> *` and there is an instance

```haskell
instance A x => B (T x)

```

would you count that as a dependency?

Anyways, the [constraints](https://hackage.haskell.org/package/constraints) package might be helpful.

---

<div class="post-metadata">

**Author:** ![B-rando](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/b-rando/32/5746_2.png) [@B-rando](https://discourse.haskell.org/u/B-rando)\
**Post date:** [September 9, 2026, 12:31am UTC](https://discourse.haskell.org/t/best-way-to-create-a-typeclass-dependency-graph/14666/4 "2026-09-09T00:31:56Z")

</div>

Thanks for the responses!

To give a bit more detail, my project has a tree of typeclasses that we use to form a tagless embedding of a generic programming language. We have an ADT called `TypeData`, and I need to know which typeclasses reference it in their method signatures, and a graph of the transitive closure of typeclasses that have those as constraints.

Because the typeclasses that I care about are so specific, I’m not sure if I’ll find an off-the-shelf solution. But if something gets part of the way, it could save me some work.