The Cabal-syntax package has a lot of short modules that export a single type and, perhaps, some closely-related functions. Is that a good way to organise a package? What are the merits/drawbacks?
I ask because the stack package has some long modules that export many types. The repository has an ancient open issue that suggests refactoring into smaller modules might speed up compilation when changes are made. I am wondering if Stack should emulate what Cabal has done.
When I read the doc of your module(s):
On odd-numbered days, I wish you split them up, so that unrelated things were in independent tabs in my web browser.
On even-numbered days, I wish you merged them, so that everything I’m using were on the same page and I would not need to keep switching between tabs. Yes, even if they were unrelated.
I would say it’s something in between many short modules and a few large modules. Large modules are sometimes ok if your task that this module is supposed to solve requires a complex solution. But often you can split of functions that are not directly related to this task. On the other hand, if your modules are too short, you would have to write a lot of import statements and come up with a lot of new module names. Personally, I wouldn’t choose the module name the same as the name of a type that resides in that module. Also, when I use types across different modules, I put them in an extra Types.hs module.
I think the primary reason is compile-time (but I compile Cabal a lot …). LicenseId is a beast: #16577: Investigate compiler performance of Distribution.SPDX.LicenseId · Issues · Glasgow Haskell Compiler / GHC · GitLab
You get to parallelise compilation of the smaller modules all while having a smaller residency (and thus faster GCs) in the process that compiles LicenseId.
It’s enough to put the biggest enums into their own file to reap most these benefits, I suppose.
Thanks for the responses and advice. In the end, I did move content from long modules into shorter ones, and that is reflected in stack-2.11.1.