Edward, Thanks for straightening me out; I see the problems better now. In particular I was missing: 1) Orphaned types (and related design issues) get in the way of splitting the package. 2) Viral dependencies work in two directions, since "upstream" packages must pick up your deps to include instances of your classes. I'm thinking out loud, so bear with me.
The problem is there is no path to get there from here. Getting another library to depend on mine, they have to pick up the brittle dependency set I have now. Splitting my package into smaller packages fails because I need to keep the instances for 3rd party data types packed with the class definitions to avoid orphan instances and poor API design. So the option to
Some class instances can go in three places: a) The source package for the type, which then picks up your deps. Bad. b) Your package, which then has a gazillion deps. Bad. c) Your sub-packages, in which case they're orphaned. Bad. I have to wonder whether (c) isn't the least of evils. Playing the advocate: - Orphaned instances are bad because of the risk of multiple instances. That risk should be low in this case; if anyone else wanted an instance of, say, a Prelude ADT for your library's class, their obvious option is to use your sub-package. - If you accept the above, then orphaning the intance in a sub-package that's associated with either the type's or the class's home is morally better than providing an instance in an unaffiliated third package. - Orphaning in sub-packages as a stopgap could make it much easier to get your class (and the instance) added to those upstream packages where it makes sense to do so. This clearly doesn't solve all parts of the problem. You may have other design concerns that make sub-packages undesirable. Even with instance definitions removed you may still have enough dependencies to deter integration. The problem probably extends beyond just class instances.
The only other alternative that I seem to have at this point in the cabal packaging system is to create a series of flags for optional functionality.
This sounds like rat hole of a different nature. You lose the ability to tell if an API is supported based on whether the package that implements it is installed. An installed and working package can cease to function after (possibly automatic) reinstallation when other packages become available. Complicated new functionality is required in Cabal. Regards, John