CODEWITHSUNDEEP
haskelltypeclass
rampion
rampion

Reputation: 89113

Create orphan instances or add spurious dependencies?

I'm working on updating my ReadArgs package. I had a request to add Arguable instances for Data.Text and FileSystem.Path.FilePath. The former is no big deal, since it's in the base package, but the latter requires system-filepath

So I could release a ReadArgs-ext package, chock full of orphan instances, or I could update the ReadArgs package with an additional external dependency. Which option makes more sense?

Upvotes: 1

Views: 150

Answers (1)

Edward Kmett
Edward Kmett

Reputation: 29982

My usual rule of thumb is to tend towards adding the instances for packages that are in the Haskell Platform, but don't involve less portable elements such as graphics. This covers both filepath and text. Since you are already dealing with the outside world for command line arguments, neither one of those seems like a particularly egregious addition.

Orphans can lead to pretty terrible problems.

I don't use them in 95% of my packages, and I go out of my way to avoid packages that use them.

The two exceptions I have at this point are a few missing monoids in reducers and a package full of vector-instances I picked up because I wasn't willing to make my entire hierarchy of packages depend on vector, downgrading everything from Safe to Trustworthy.

I find when I'm tempted to add an orphan instance, I can usually work around it by providing some kind of WrappedMonad-like newtype wrapper for lifting or lowering another class.

Upvotes: 3

Related Questions