[Haskell-cafe] Re: Configuring cabal dependencies at install-time

[John Dorsey]

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