Ryan Scott

A variant of this has been proposed before (and rejected) in https://github.com/bos/text/issues/106.

Indeed, I'd be fine with fixing (1) in isolation. As for (2), there are a number of solutions currently available. There's @bos's own [`text-format`](http://hackage.haskell.org/package/text-format), and there's also my own [`text-show`](http://hackage.haskell.org/package/text-show)...

Sure, I'm not proposing that we implement (2) in `text`. (I only mention it since some folks here appear to want (2), or are at least waggling their eyebrows furtively...

This is pretty surprising to me, since some datatypes which currently have `Distributive` instances do not have `Monad` instances! For example, `Compose` from `transformers`.

But that still feels funny to me, since the [documentation](https://hackage.haskell.org/package/adjunctions-4.2.1/docs/Data-Functor-Rep.html#t:Representable) in `adjunctions` claims that every `Distributive` instance admits a `Representable` instance, which gives rise to an implementation of [`bind`](https://hackage.haskell.org/package/adjunctions-4.2.1/docs/Data-Functor-Rep.html#t:Representable). Does...

I've "backported" the patch from #65 in [this pull request](https://github.com/ekmett/distributive/pull/68).

Thanks! There's [one build failure](https://github.com/dreixel/generic-deriving/pull/78/checks?check_run_id=3755299669#step:18:30) on GHC 7.0: ``` [ 5 of 23] Compiling Generics.Deriving.Absurd ( src/Generics/Deriving/Absurd.hs, /__w/generic-deriving/generic-deriving/dist-newstyle/build/x86_64-linux/ghc-7.0.4/generic-deriving-1.14.1/build/Generics/Deriving/Absurd.o ) src/Generics/Deriving/Absurd.hs:11:12: Not in scope: type constructor or class `V1' ``` This...

The latter option (make `cabal bench` self-contained) would be greatly preferred, since I'm simply downloading a bunch of benchmarked programs from Hackage and invoking `bench` on all of them to...

`optparse-applicative` recently made two releases that support `prettyprinter`: * `optparse-applicative-0.17.1.0` supports `ansi-wl-pprint-1.*`, which re-exports `prettyprinter` functionality. * `optparse-applicative-0.18.0.0` drops its `ansi-wl-pprint` dependency and instead depends on `prettyprinter` directly. I think...

See #275 (which widens `optparse-applicative` support) and #276 (which requires `optparse-applicative-0.18.*` as the minimum).