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

On Jan 26, 2017, at 07:52, Edward Kmett wrote:

I'm similarly weakly +1 on adding Data.Functor.Zero, but -1 on One because of the existence of Proxy.

-Edward

On Wed, Jan 25, 2017 at 8:36 PM, Ryan Scott wrote: You linked to the Trac issue [1], but for the purposes of motivating this proposal, I think it's important that we reiterate why you want this.

First of all, I think we should be clear that you're proposing to add these in the modules:

* Data.Functor.One * Data.Functor.Zero

Right? Not literally "Data.Functor", as the title might mislead you into believing.

Also, for a reason why you might want these - there are currently analogs in the GHC.Generics [2] module:

* data U1 a = U1 -- isomorphic to One * data V1 a -- isomorphic to Zero

But this is an unfortunate situation, since I'd rather not recommend that folks import a generics library to use what should be general-purpose datatypes.

Now, as for the proposal itself:

* I'm weakly +1 in favor of Zero. I think it'd be nice to have a proper * -> * counterpart to Void in base (that isn't V1, obviously). * I'm weakly -1 in favor of One, simply because we already have Data.Proxy, which came first.

Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/ticket/13177 [2] http://hackage.haskell.org/package/base-4.9.1.0/docs/GHC-Generics.html _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

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

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