There is a large downside to duplication: Once you have the Product
functor, you want to be able to talk about its unit. Such multi-parameter
typeclasses and type families often talk about 'the' product instance or
'the' initial or terminal object for a given category. I have plenty of
these classes lying around in packages on and off hackage.
Once you for all intents and purposes duplicate the type, in base no less,
the community painfully splits into two incompatible subsets.
We already have a fair bit of that going on with Const vs Constant, though,
at least there the bias is almost overwhelmingly in the Const direction,
but that sure isn't a pattern I'm eager to repeat.
-Edward
On Thu, Jan 26, 2017 at 12:23 PM, Bryan Richter
On Thu, Jan 26, 2017 at 08:43:05AM -0800, Eric Seidel wrote:
I see the argument against One (duplicating types), but from a user’s perspective I imagine it would be quite annoying to import Zero from Data.Functor, but then be forced to
1. remember that Proxy is isomorphic to One 2. import Proxy from elsewhere
We could add a type alias One = Proxy, and maybe even a pattern synonym for the constructor, to alleviate the UX issue. But that might bring issues of its own.
I’m neutral on the actual proposal though, as I don’t consider myself a potential user.
I second all of Eric's points.
From a user's perspective, isomorphism does not equate to duplication when considering other factors such as home module, intended use, discoverability, connotation, ....
-Bryan
_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries