Adding Fixed Point Data Types to base

[Andrew Martin]

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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20161016/64291a67/attachment-0001.html>