Resolve name collsion of `first` and `second` by Control.Arrow and Data.Bifunctor

[Edward Kmett]

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 at 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 at gmail.com>
> *To:* "Alexandre Rodrigues"<alexandrer_b at outlook.com>;
> *Cc:* "박신환"<ndospark320 at naver.com>; "Haskell Libraries"<libraries at 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20180509/26ed5948/attachment.html>