Good examples of structuring a multi-module library?

#1

I’m looking for good examples of Haskell libraries with multiple, possibly nested modules to see how they have handled project exports and ergonomic imports for library clients.

I notice some projects provide a project-specific “prelude”, allowing something like:

import MyProject.Core

and possibly:

import MyProject.Extras

if needed. I think to do this the Core module must be importing and reexporting the “core” internal library modules? I wonder if that module needs to also reexport third-party modules used in the module type definitions?

Any advice much appreciated.

1 Like
#2

I would re-export the common things from MyProject instead of a submodule. Re-exporting from other libraries is a versioning nightmare as a breaking change in those libraries may be a breaking change in your lib.

I think opaleye has a good module structure!

#3

IMO Core and Extras isn’t even a good split. How would one know without further digging what’s considered “extras”?

I’d rather have users making their own preludes and focus on providing a sane module tree grouped by functionality provided.

#4

Thanks – I’ll checkout opealeye.

#5

Good point – thanks.

#6

Here’s a plug for @NorfairKing :slight_smile: While you can get this from just about any of his projects, one of the purposes of https://github.com/NorfairKing/smos is to be an example we can learn from. The codebase explicitly aims for the extensive and ergonomic application of a variety of best practices (including module imports and exports, libraries, etc). This is a good example of what a moderately large project can look like with those practices applied, and is not just a couple commits in a fly-by-night toy blog post.

1 Like
#7

There’s an excellent blog post by Gabriella Gonzalez about structuring modules in Haskell projects:

3 Likes