Thanks for weighing in. It is possible to use cabal flags + CPP to work around this, although I don't like doing that for the reasons you would expect. I'm also not typically comfortable opening up an issue to ask a package maintainer to add a flag to enable conditional dependencies for instances. I believe that there is precedent for pulling data types that offer a good abstraction into base (ie, moving Data.Functor.* from transformers to base, moving Bifunctor into base), but I don't know exactly what threshold needs to be cleared to make a compelling argument for doing this.

-Andrew Martin

On Sun, Oct 16, 2016 at 2:49 PM, Ruben Astudillo <ruben.astud@gmail.com> wrote:

On 16/10/16 11:21, Andrew Martin wrote:
> The advantage this offers is that Free and Cofree would be able to
> enjoy a greater number of typeclass instances provided libraries
> across the ecosystem. As it stands, adding the somewhat heavy `free`
> dependency is not a good choice for libraries like `aeson`,
> `mustache`, and `hashable`. In the case of Fix, the ecosystem
> currently lacks a canonical library that provides it
> (recursion-schemes and data-fix both offer the same definition though,
> and various tutorials all define it the same way). It could benefit
> from the new instances as well.

This is a problem I see a lot, having to pull a "heavy" dependency to
implement an instance and avoid orphans. I don't favor making a monolith
in `base` for this, it goes against modularity and is a maintainer risk
for base. Can cabal flags + CPP be abused to implement the instances on
demand if the constrains are meet?. That would solve this problem at the
cost of having to remember package-flags.

-- Ruben Astudillo

-Andrew Thaddeus Martin