rfc: Additions to Data.Either (take 2)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

rfc: Additions to Data.Either (take 2)

João Cristóvão
Hello,

So following Carter Schonwald suggestion of creating a new thread, but not literally, since the amount of combinations would be huge, here is my own humble attempt to gather all hypothesis discussed into separate proposals, for your voting pleasure.
(Some are mutually exclusive, some are not)

Proposal 0:
----------------

Do nothing

Proposal 1:
----------------
Add no new code, but document Data.Either to mention how to use `left` and (+++) from Control.Arrow

Proposal 2:
----------------
Document Control.Arrow to exemplify the (->) instance usage.

Proposal 3:
----------------

Implement mapLeft in Data.Either

3a) ... as (a -> b) -> Either a c -> Either b c (so that is easy to follow)
3b) ... as Control.Arrow.left
3c) ... and also redefine the -> instance of Control.Arrow.left as mapLeft

Proposal 4:
----------------

Implement mapBoth in Data.Either

4a) ... as (a -> b) -> (c -> d) -> Either a c -> Either b d (so that is easy to follow)
4b) ... as Control.Arrow.(+++)
4c) ... and also redefine the -> instance of Control.Arrow.(+++) as mapBoth

Proposal 5:
----------------

== Proposal 4, using the mapEither name instead.

Proposal 6:
----------------

Implement mapRight in Data.Either

6a) ... as (b -> c) -> Either a b -> Either a c
6b) ... as fmap

Proposal 7:
----------------

Don't implement mapRight, but include documentation in Data.Either stating that it is just fmap.

Proposal 8:
----------------

Bring bifunctors to base.


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: rfc: Additions to Data.Either (take 2)

João Cristóvão
And my own votes:

0) (-1)
1) (-1)
2) (+1)
3.a) (+1)
3.b) (0)
3.c) (+1)
4.a) (+1)
4.b) (0)
4.c) (+1)
5) (0)
6a) (-1)
6b) (-1)
7) (+1)
8) (+1)


2014-04-21 21:01 GMT+01:00 João Cristóvão <[hidden email]>:
Hello,

So following Carter Schonwald suggestion of creating a new thread, but not literally, since the amount of combinations would be huge, here is my own humble attempt to gather all hypothesis discussed into separate proposals, for your voting pleasure.
(Some are mutually exclusive, some are not)

Proposal 0:
----------------

Do nothing

Proposal 1:
----------------
Add no new code, but document Data.Either to mention how to use `left` and (+++) from Control.Arrow

Proposal 2:
----------------
Document Control.Arrow to exemplify the (->) instance usage.

Proposal 3:
----------------

Implement mapLeft in Data.Either

3a) ... as (a -> b) -> Either a c -> Either b c (so that is easy to follow)
3b) ... as Control.Arrow.left
3c) ... and also redefine the -> instance of Control.Arrow.left as mapLeft

Proposal 4:
----------------

Implement mapBoth in Data.Either

4a) ... as (a -> b) -> (c -> d) -> Either a c -> Either b d (so that is easy to follow)
4b) ... as Control.Arrow.(+++)
4c) ... and also redefine the -> instance of Control.Arrow.(+++) as mapBoth

Proposal 5:
----------------

== Proposal 4, using the mapEither name instead.

Proposal 6:
----------------

Implement mapRight in Data.Either

6a) ... as (b -> c) -> Either a b -> Either a c
6b) ... as fmap

Proposal 7:
----------------

Don't implement mapRight, but include documentation in Data.Either stating that it is just fmap.

Proposal 8:
----------------

Bring bifunctors to base.



_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: rfc: Additions to Data.Either (take 2)

Nathan Bouscal
In reply to this post by João Cristóvão
+1 on proposals 2, 7, and 8. Mostly indifferent on the others.


On Mon, Apr 21, 2014 at 4:01 PM, João Cristóvão <[hidden email]> wrote:
Hello,

So following Carter Schonwald suggestion of creating a new thread, but not literally, since the amount of combinations would be huge, here is my own humble attempt to gather all hypothesis discussed into separate proposals, for your voting pleasure.
(Some are mutually exclusive, some are not)

Proposal 0:
----------------

Do nothing

Proposal 1:
----------------
Add no new code, but document Data.Either to mention how to use `left` and (+++) from Control.Arrow

Proposal 2:
----------------
Document Control.Arrow to exemplify the (->) instance usage.

Proposal 3:
----------------

Implement mapLeft in Data.Either

3a) ... as (a -> b) -> Either a c -> Either b c (so that is easy to follow)
3b) ... as Control.Arrow.left
3c) ... and also redefine the -> instance of Control.Arrow.left as mapLeft

Proposal 4:
----------------

Implement mapBoth in Data.Either

4a) ... as (a -> b) -> (c -> d) -> Either a c -> Either b d (so that is easy to follow)
4b) ... as Control.Arrow.(+++)
4c) ... and also redefine the -> instance of Control.Arrow.(+++) as mapBoth

Proposal 5:
----------------

== Proposal 4, using the mapEither name instead.

Proposal 6:
----------------

Implement mapRight in Data.Either

6a) ... as (b -> c) -> Either a b -> Either a c
6b) ... as fmap

Proposal 7:
----------------

Don't implement mapRight, but include documentation in Data.Either stating that it is just fmap.

Proposal 8:
----------------

Bring bifunctors to base.


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries



_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: rfc: Additions to Data.Either (take 2)

Tobias Florek
In reply to this post by João Cristóvão
thanks joão for the write-up.

 > Proposal 1:
 > Add no new code, but document Data.Either to mention how to use `left`
 > and (+++) from Control.Arrow

(+1 for documentation, but that's not what that proposal is about)

 > Proposal 2:
 > Document Control.Arrow to exemplify the (->) instance usage.

+1

 > Proposal 7:
 > Don't implement mapRight, but include documentation in Data.Either
 > stating that it is just fmap.

+1

 > Proposal 8:
 > Bring bifunctors to base.

(my favorite by far)
+1

all others i am ignorant about.

cheers,
  tobias florek
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: rfc: Additions to Data.Either (take 2)

Dominique Devriese-2
In reply to this post by João Cristóvão
First, I think Edward suggested to bring only some main *parts* of bifunctors to
base, not the full package.  Is this what you meant with proposal 8?

If so, I'm +1 on proposals 3,4,5,7 and 8, -1 to proposal 1,
indifferent on the others.  Proposal 8 is my favourite.

Regards,
Dominique

2014-04-21 22:01 GMT+02:00 João Cristóvão <[hidden email]>:

> Hello,
>
> So following Carter Schonwald suggestion of creating a new thread, but not
> literally, since the amount of combinations would be huge, here is my own
> humble attempt to gather all hypothesis discussed into separate proposals,
> for your voting pleasure.
> (Some are mutually exclusive, some are not)
>
> Proposal 0:
> ----------------
>
> Do nothing
>
> Proposal 1:
> ----------------
> Add no new code, but document Data.Either to mention how to use `left` and
> (+++) from Control.Arrow
>
> Proposal 2:
> ----------------
> Document Control.Arrow to exemplify the (->) instance usage.
>
> Proposal 3:
> ----------------
>
> Implement mapLeft in Data.Either
>
> 3a) ... as (a -> b) -> Either a c -> Either b c (so that is easy to follow)
> 3b) ... as Control.Arrow.left
> 3c) ... and also redefine the -> instance of Control.Arrow.left as mapLeft
>
> Proposal 4:
> ----------------
>
> Implement mapBoth in Data.Either
>
> 4a) ... as (a -> b) -> (c -> d) -> Either a c -> Either b d (so that is easy
> to follow)
> 4b) ... as Control.Arrow.(+++)
> 4c) ... and also redefine the -> instance of Control.Arrow.(+++) as mapBoth
>
> Proposal 5:
> ----------------
>
> == Proposal 4, using the mapEither name instead.
>
> Proposal 6:
> ----------------
>
> Implement mapRight in Data.Either
>
> 6a) ... as (b -> c) -> Either a b -> Either a c
> 6b) ... as fmap
>
> Proposal 7:
> ----------------
>
> Don't implement mapRight, but include documentation in Data.Either stating
> that it is just fmap.
>
> Proposal 8:
> ----------------
>
> Bring bifunctors to base.
>
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries
>
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: rfc: Additions to Data.Either (take 2)

Oliver Charles-3
In reply to this post by João Cristóvão
On Mon, Apr 21, 2014 at 9:01 PM, João Cristóvão <[hidden email]> wrote:

Proposal 0:
----------------

Do nothing

Seeing as this has come up a bunch of times, -1 - as we clearly need to do something

Proposal 1:
----------------
Add no new code, but document Data.Either to mention how to use `left` and (+++) from Control.Arrow

+1
 
Proposal 2:
----------------
Document Control.Arrow to exemplify the (->) instance usage.

More examples is in general a good idea - I see no harm in this. +1
 
Proposal 3:
----------------

Proposal 4:
----------------
 

Proposal 5:
----------------

== Proposal 4, using the mapEither name instead.
 
Indifferent on these.  
 
Proposal 6:
----------------

Implement mapRight in Data.Either

6a) ... as (b -> c) -> Either a b -> Either a c
6b) ... as fmap

-1 on this, as we don't have 'mapJust' and Functor is hardly an esoteric type class.
 

Proposal 7:
----------------

Don't implement mapRight, but include documentation in Data.Either stating that it is just fmap.

Again, more documentation is almost always a good thing. +1
 

Proposal 8:
----------------

Bring bifunctors to base.

-1, and seems at ends with the split base proposals. I don't see much value in growing base a whole lot more. I'm probably opening a whole 'nother can of worms. Apologies ;)


- ocharles

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: rfc: Additions to Data.Either (take 2)

Aloïs Cochard
+1 for proposal 1

Strongly against adding other map* functions.


On 21 April 2014 21:43, Oliver Charles <[hidden email]> wrote:
On Mon, Apr 21, 2014 at 9:01 PM, João Cristóvão <[hidden email]> wrote:

Proposal 0:
----------------

Do nothing

Seeing as this has come up a bunch of times, -1 - as we clearly need to do something

Proposal 1:
----------------
Add no new code, but document Data.Either to mention how to use `left` and (+++) from Control.Arrow

+1
 
Proposal 2:
----------------
Document Control.Arrow to exemplify the (->) instance usage.

More examples is in general a good idea - I see no harm in this. +1
 
Proposal 3:
----------------

Proposal 4:
----------------
 

Proposal 5:
----------------

== Proposal 4, using the mapEither name instead.
 
Indifferent on these.  
 
Proposal 6:
----------------

Implement mapRight in Data.Either

6a) ... as (b -> c) -> Either a b -> Either a c
6b) ... as fmap

-1 on this, as we don't have 'mapJust' and Functor is hardly an esoteric type class.
 

Proposal 7:
----------------

Don't implement mapRight, but include documentation in Data.Either stating that it is just fmap.

Again, more documentation is almost always a good thing. +1
 

Proposal 8:
----------------

Bring bifunctors to base.

-1, and seems at ends with the split base proposals. I don't see much value in growing base a whole lot more. I'm probably opening a whole 'nother can of worms. Apologies ;)


- ocharles

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries




--
Alois Cochard

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: rfc: Additions to Data.Either (take 2)

Herbert Valerio Riedel
In reply to this post by João Cristóvão
On 2014-04-21 at 22:01:34 +0200, João Cristóvão wrote:
> Proposal 1:
> ----------------
> Add no new code, but document Data.Either to mention how to use `left` and
> (+++) from Control.Arrow

+1

> Proposal 2:
> ----------------
> Document Control.Arrow to exemplify the (->) instance usage.

+1

> Proposal 3:
> ----------------
>
> Implement mapLeft in Data.Either
>
> 3a) ... as (a -> b) -> Either a c -> Either b c (so that is easy to follow)
> 3b) ... as Control.Arrow.left
> 3c) ... and also redefine the -> instance of Control.Arrow.left as mapLeft

-1

> Proposal 4:
> ----------------
>
> Implement mapBoth in Data.Either
>
> 4a) ... as (a -> b) -> (c -> d) -> Either a c -> Either b d (so that is
> easy to follow)
> 4b) ... as Control.Arrow.(+++)
> 4c) ... and also redefine the -> instance of Control.Arrow.(+++) as mapBoth

-1

> Proposal 5:
> ----------------
>
> == Proposal 4, using the mapEither name instead.

-1

> Proposal 6:
> ----------------
>
> Implement mapRight in Data.Either
>
> 6a) ... as (b -> c) -> Either a b -> Either a c
> 6b) ... as fmap

-1

> Proposal 7:
> ----------------
>
> Don't implement mapRight, but include documentation in Data.Either stating
> that it is just fmap.

+1

> Proposal 8:
> ----------------
>
> Bring bifunctors to base.

+1    (btw, afaik the idea is to bring only the core parts of bifunctors into base)
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: rfc: Additions to Data.Either (take 2)

Andreas Abel
In reply to this post by João Cristóvão
My votes:

On 21.04.14 10:01 PM, João Cristóvão wrote:
> Proposal 0:
> ----------------
>
> Do nothing

-1

> Proposal 1:
> ----------------
> Add no new code, but document Data.Either to mention how to use `left`
> and (+++) from Control.Arrow

-1 That would not show up "first class", e.g. not in synopsis...

> Proposal 2:
> ----------------
> Document Control.Arrow to exemplify the (->) instance usage.

+1

> Proposal 3:
> ----------------
>
> Implement mapLeft in Data.Either
>
> 3a) ... as (a -> b) -> Either a c -> Either b c (so that is easy to follow)
> 3b) ... as Control.Arrow.left
> 3c) ... and also redefine the -> instance of Control.Arrow.left as mapLeft

+1

> Proposal 4:
> ----------------
>
> Implement mapBoth in Data.Either
>
> 4a) ... as (a -> b) -> (c -> d) -> Either a c -> Either b d (so that is
> easy to follow)
> 4b) ... as Control.Arrow.(+++)
> 4c) ... and also redefine the -> instance of Control.Arrow.(+++) as mapBoth

+1

> Proposal 5:
> ----------------
>
> == Proposal 4, using the mapEither name instead.

-1 Unfortunately, that is too close to

   mapMaybe :: (a -> Maybe b) -> [a] -> [b]

which is a misnomer, should have been called filterMaybe.

> Proposal 6:
> ----------------
>
> Implement mapRight in Data.Either
>
> 6a) ... as (b -> c) -> Either a b -> Either a c
> 6b) ... as fmap

+1

> Proposal 7:
> ----------------
>
> Don't implement mapRight, but include documentation in Data.Either
> stating that it is just fmap.

Where is the radio button?

> Proposal 8:
> ----------------
>
> Bring bifunctors to base.

+1

--
Andreas Abel  <><      Du bist der geliebte Mensch.

Theoretical Computer Science, University of Munich
Oettingenstr. 67, D-80538 Munich, GERMANY

[hidden email]
http://www2.tcs.ifi.lmu.de/~abel/
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: rfc: Additions to Data.Either (take 2)

Eric Mertens
In reply to this post by João Cristóvão

Proposal 0:
----------------

Do nothing

(+1) I'd be OK with the outcome being nothing changing, but in the case that it doesn't I have the following take
 

Proposal 1:
----------------
Add no new code, but document Data.Either to mention how to use `left` and (+++) from Control.Arrow

(-1) I don't find Control.Arrow to be a compelling abstraction and I don't want to drive more people to it only to use it simply for its (->) instances. Additionally I don't want think that learning more operators is the solution to applying functions to Either values.
 

Proposal 2:
----------------
Document Control.Arrow to exemplify the (->) instance usage.

(0) I'm OK with any changes that happen inside the Control.Arrow module
 

Proposal 3:
----------------

Implement mapLeft in Data.Either

3a) ... as (a -> b) -> Either a c -> Either b c (so that is easy to follow)
3b) ... as Control.Arrow.left
3c) ... and also redefine the -> instance of Control.Arrow.left as mapLeft

(+1) for 3a. We don't need Arrow leaking out of its module. mapLeft is the actual operation in question. A user looking for operations on Either can switch to a more general operation later when it turns out he's writing a more general function.
 

Proposal 4:
----------------

Implement mapBoth in Data.Either

4a) ... as (a -> b) -> (c -> d) -> Either a c -> Either b d (so that is easy to follow)
4b) ... as Control.Arrow.(+++)
4c) ... and also redefine the -> instance of Control.Arrow.(+++) as mapBoth


(-1) the Both name invokes tuples for me
 
Proposal 5:
----------------

== Proposal 4, using the mapEither name instead.

(+1) same as 3a
 

Proposal 6:
----------------

Implement mapRight in Data.Either

6a) ... as (b -> c) -> Either a b -> Either a c
6b) ... as fmap

(+1) 6a. The code should be clear and gains nothing by exposing fmap's type or implementation and it should be an error for someone to use mapRight on a non-Either value
 
Proposal 7:
----------------

Don't implement mapRight, but include documentation in Data.Either stating that it is just fmap.

(-1) While it is true that fmap is mapRight for Either, that doesn't mean that the mapRight operation doesn't stand on its own.
 

Proposal 8:
----------------

Bring bifunctors to base.

(0) I'm fine with bifunctors moving into base, but I don't think it's relevant to this discussion. While it is the case that the Bifunctor abstraction also subsumes a map[Left,Right,Either], these operations continue to stand on there own.

I'd advocate for using the general operations when the generality is called for and useful, not as a way to save on names. I similarly consider it inappropriate to remove (.) in favor of fmap

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: rfc: Additions to Data.Either (take 2)

Joachim Breitner-2
In reply to this post by João Cristóvão
Hi,

Am Montag, den 21.04.2014, 21:01 +0100 schrieb João Cristóvão:

> Proposal 3:
> ----------------
>
> Implement mapLeft in Data.Either
>
> 3a) ... as (a -> b) -> Either a c -> Either b c (so that is easy to
> follow)
> 3b) ... as Control.Arrow.left
> 3c) ... and also redefine the -> instance of Control.Arrow.left as
> mapLeft
+1
(no strong opinion about the implementation)

> Proposal 4:
> ----------------
>
> Implement mapBoth in Data.Either
>
> 4a) ... as (a -> b) -> (c -> d) -> Either a c -> Either b d (so that
> is easy to follow)
> 4b) ... as Control.Arrow.(+++)
> 4c) ... and also redefine the -> instance of Control.Arrow.(+++) as
> mapBoth
+1

> Proposal 5:
> ----------------
>
> == Proposal 4, using the mapEither name instead.

+1

> Proposal 6:
> ----------------
>
> Implement mapRight in Data.Either
>
> 6a) ... as (b -> c) -> Either a b -> Either a c
> 6b) ... as fmap

+1

Greetings,
Joachim

--
Joachim “nomeata” Breitner
  [hidden email]http://www.joachim-breitner.de/
  Jabber: [hidden email]  • GPG-Key: 0xF0FBF51F
  Debian Developer: [hidden email]


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

signature.asc (836 bytes) Download Attachment