Add Zero and One to Data.Functor (mirroring V1, U1)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Add Zero and One to Data.Functor (mirroring V1, U1)

Baldur Blöndal
Deadline of 2 weeks.

Original discussion: ⁽¹⁾

data Zero a
data One  a = One

Same definitions as in ‘trivia’ package,⁽²⁾
if a consensus is reached we can update
the documentation for Free:⁽³⁾

“Free Zero” is isomorphic to Identity.

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Add Zero and One to Data.Functor (mirroring V1, U1)

Ryan Scott
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Add Zero and One to Data.Functor (mirroring V1, U1)

Edward Kmett-2
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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Add Zero and One to Data.Functor (mirroring V1, U1)

Eric Seidel-3
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 <[hidden email]> 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 <[hidden email]> 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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Add Zero and One to Data.Functor (mirroring V1, U1)

Bryan Richter-2
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Add Zero and One to Data.Functor (mirroring V1, U1)

Eric Mertens
In reply to this post by Baldur Blöndal
Hi everyone,

I don't think it's obvious why these type need to be in the base package itself. It makes sense that the GHC.Generics types are in base because GHC needs access to them to derive Generic. We already have Proxy in base. The trivia package was released in 2014 but no other package has needed that functionality enough to depend on it. What problem is being solved?

I think the types provided by packages like transformers are more important to general Haskell programming, and I'm quite happy to have those types in a separate package.

Best regards,
Eric Mertens

On Tue, Jan 24, 2017 at 11:18 AM Baldur Blöndal <[hidden email]> wrote:
Deadline of 2 weeks.

Original discussion: ⁽¹⁾

data Zero a
data One  a = One

Same definitions as in ‘trivia’ package,⁽²⁾
if a consensus is reached we can update
the documentation for Free:⁽³⁾

“Free Zero” is isomorphic to Identity.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Add Zero and One to Data.Functor (mirroring V1, U1)

Edward Kmett-2
In reply to this post by Bryan Richter-2
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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries



_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Loading...