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, 박신환 <ndospark320@naver.com> 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"<emertens@gmail.com>
To: "Alexandre Rodrigues"<alexandrer_b@outlook.com>;
Cc: "박신환"<ndospark320@naver.com>; "Haskell Libraries"<libraries@haskell.org>;
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