I'm opposed to changing the names in either module. In modern code it should be fairly rare to import Control.Arrow. In the cases that both are needed qualified imports are available, and it wouldn't be worth breaking existing code by renaming the class methods of Bifunctor. On Tue, May 8, 2018 at 7:58 AM Alexandre Rodrigues wrote:

Name collisions are always an issue, and I think you raise a valid point. However, in this case, does Haskell not already offer a solution? Qualified imports do add some overhead, but doing

```

import qualified Control.Arrow as A

import qualified Data.Bifunctor as B

foo :: Foo

foo = f . A.first . g

baz :: Baz

baz = h . B.first . i

```

does not seem too difficult.

On 08-05-2018 15:35, 박신환 wrote:

I had to import both Control.Arrow and Data.Bifunctor, and the name collision is annoying.

`first` and `second` from Data.Bifunctor should be given other names. I suggest (<$<) and (>$>), respectively.

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

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

It is worth noting that first and second from Data.Bifunctor were named to serve as an argument that in general it is seems useful to abstract over the bifunctor than the arrow type, in an attempt to help lead people away from Control.Arrow. My experience and the data I had at the time based on data mining hackage was that most of the code that was importing Control.Arrow, was importing it to work with just the (->) instane, and to get a couple of combinators like first and second. The clash was a rather deliberate choice. Data.Profunctor, which offered yet a third color for the bikeshed actually deliberately moving "out of the way" of the names taken by Data.Bifunctor and Control.Arrow and I've pretty much regretted the ' s in the names ever since. So I'm not terribly inclined to rename the combinators that live in each one of the classes. On the other hand, exporting redundant alternatively named aliases from the module would then introduce yet another name for people to get hung up on, and if it has exactly the same type signature they'd have to then know which one was in the class and which one is not. This is rather annoying and hard to keep track of information. But it is worth noting that 'import ... as ...' doesnt required the use of qualified, so with import Control.Arrow as A import Data.Bifunctor as B now you can use almost all the combinators and operators from Control.Arrow except first and second unqualified _and_ almost all the combinators from Data.Bifunctor unqualified, but need to refer to A.first or B.first and A.second or B.second due to the clash. This can be locally disambiguated by users with no additional information about what has been added in some bleeding edge version of Data.Bifunctor. We have qualified imports for covering this scenario. Globally unique names are generally going to be impossible to maintain, and additional redundant aliases come with additional cognitive overhead to remember that they exist, and which one is the redefinable one that lives in the class, so this request doesn't come 'for free'. -Edward On Wed, May 9, 2018 at 2:34 AM, 박신환 wrote:

It still seems worthy to add the aliases for Data.Bifunctor.first and Data.Bifunctor.second. Hence:

import Control.Arrow

import Data.Bifunctor hiding (first, second)

and we don't need to have the methods qualified.

-----Original Message----- *From:* "Eric Mertens" *To:* "Alexandre Rodrigues"; *Cc:* "박신환"; "Haskell Libraries"; *Sent:* 2018-05-09 (수) 01:04:12 *Subject:* Re: Resolve name collsion of `first` and `second` by Control.Arrow and Data.Bifunctor

I'm opposed to changing the names in either module. In modern code it should be fairly rare to import Control.Arrow. In the cases that both are needed qualified imports are available, and it wouldn't be worth breaking existing code by renaming the class methods of Bifunctor.

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

On Wed, 9 May 2018, Wolfgang Jeltsch wrote:

Eric Mertens wrote:

In modern code it should be fairly rare to import Control.Arrow. 

Edward Kmett wrote:

[…] in an attempt to help lead people away from Control.Arrow.

I’m irritated. Can someone explain what is wrong about Control.Arrow?

I think there is nothing wrong about Arrow, but people abused Arrow.first and Arrow.second for plain function arrow and now we have Bifunctor which is the more appropriate abstraction for most uses of 'first' and 'second'. (Though I guess that most uses need no abstraction at all.)

On Wed, 9 May 2018, Wolfgang Jeltsch wrote:

I think using Bifunctor.first and Bifunctor.second is as much an abuse as using Arrow.first and Arrow.second. When using Arrow you specialize the arrow type to (->), but when using Bifunctor you specialize the bifunctor type to (,).

I actually use my own specialised mapFst and mapSnd functions from utility-ht. I also found that I sometimes need strict versions of these functions in order to prevent space leaks.