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
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