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

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

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

박신환

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

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

Alexandre Rodrigues

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 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
|

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

Eric Mertens
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 <[hidden email]> 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 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
|

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

박신환

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"<[hidden email]>
To: "Alexandre Rodrigues"<[hidden email]>;
Cc: "박신환"<[hidden email]>; "Haskell Libraries"<[hidden email]>;
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Edward Kmett-2
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, 박신환 <[hidden email]> 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"<[hidden email]>
To: "Alexandre Rodrigues"<[hidden email]>;
Cc: "박신환"<[hidden email]>; "Haskell Libraries"<[hidden email]>;
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
[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
|

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

Wolfgang Jeltsch-3
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?

All the best,
Wolfgang

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

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

Henning Thielemann

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.)
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Wolfgang Jeltsch-3
Am Mittwoch, den 09.05.2018, 13:49 +0200 schrieb Henning Thielemann:

> 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.)

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 (,).



All the best,
Wolfgang
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Henning Thielemann

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