Where do QuickCheck instances belong in a cabal package?

Question

I have a cabal package that exports a type NBT which might be useful for other developers. I\'ve gone through the trouble of defining an Arbitrary instance for my t

Answer 1

On the basis of not much specific experience, but a general desire for robustness, the guiding principle for package dependencies should perhaps be

From each according to their ability; to each according to their need.

It's good to keep the dependencies of a package to the minimum needed for its essential functionality. That suggests option 3 or option 4 to me. Of course, it's a pain to chop the package up so much. If options are capable of expressing the conditionality involved, then option 4 sounds like a sensible approach, based on using language effectively to say what you mean.

It would be really good if a consensus emerged about which one switch we need to flick to get the testing kit as well as the basic functionality.

It's also clear that there's room for refinement here. It's amazing that Cabal works as well as it does, but it could allow for more sophisticated notions of "package", perhaps after the manner of the SML module system. Translating dependencies into function types, we basically get to write

simplePackage :: (Dependency1, .., Dependencyn) -> Deliverable

but one could imagine more elaborate combinations of products and functions, like

fancyPackage :: BasicDependency -> (BasicDeliverable, HelpfulExtras -> Gravy)

Until then, pick the option that most accurately reflects the actual deal. And tell us about it, so we can build that consensus.

Answer 2

The problem comes down to: how likely is it that someone using your library will be wanting to run QuickCheck tests using your NBT type?

If it is likely, and the Arbitrary instance is detailed (and thus not likely to change for different people), it would probably be best to ship it with your package, especially if you're going to make sure you keep updating the package (as for using a flag or not, that comes down to a bit of personal preference). If the instance is relatively simple however (and thus more likely that people would want to customise it), then it might be an idea to just provide a sample instance in the documentation.

If the type is primarily internal in nature and not likely to be used by others wanting to run tests, then using a flag to conditionally bring in QuickCheck is probably the best way to go to avoid unnecessary dependencies (i.e. the test suite is there just so you can test the package).

I'm not a fan of having QuickCheck-only packages in general, though it might be useful in some situations.