Overloaded names for Map/Set?

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

Overloaded names for Map/Set?

Andreas Klebinger
Hello devs,

I would appreciate feedback on the idea in
https://gitlab.haskell.org/ghc/ghc/merge_requests/934

Maps/Sets in GHC for the most part offer the same basic functionality
but their interfaces differ.
In order to make this easier to work with I propose using overloading
via IsSet/IsMap classes.

The goal is to make working with these data structures simpler by having
a uniform interface
when it comes to names and argument orders.

There are downsides, but to me they seem minor. Error messages can be
more confusing when one
get's the types wrong. We have to import the class to use it and the like.
However overall I think making code easier by not having to remember the
naming scheme + argument order
for the different possible instances would make this worthwhile.

But GHC isn't my project but one of the community so please voice your
opinion on the matter on the
merge request!

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

Re: Overloaded names for Map/Set?

Brandon Allbery
For what it's worth, the Edison packages provide such interfaces for many structures. You might want to ask about experiences. http://hackage.haskell.org/package/EdisonCore

On Fri, May 24, 2019, 10:12 Andreas Klebinger <[hidden email]> wrote:
Hello devs,

I would appreciate feedback on the idea in
https://gitlab.haskell.org/ghc/ghc/merge_requests/934

Maps/Sets in GHC for the most part offer the same basic functionality
but their interfaces differ.
In order to make this easier to work with I propose using overloading
via IsSet/IsMap classes.

The goal is to make working with these data structures simpler by having
a uniform interface
when it comes to names and argument orders.

There are downsides, but to me they seem minor. Error messages can be
more confusing when one
get's the types wrong. We have to import the class to use it and the like.
However overall I think making code easier by not having to remember the
naming scheme + argument order
for the different possible instances would make this worthwhile.

But GHC isn't my project but one of the community so please voice your
opinion on the matter on the
merge request!

Cheers
Andreas
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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

Re: Overloaded names for Map/Set?

Iavor Diatchki
In reply to this post by Andreas Klebinger
Hello,

I think refactoring to use consistent naming is a good idea, but I am not sure about the class idea.

To see if it is viable, we should list the types in question and the operations we'd like to overload.  

I find that with containers there tend to be two cases: either the operations are similar but not exactly the same and you have to do type hackery to make things fit, or you realize that you can just use the same type in multiple places.

Iavor


On Fri, May 24, 2019, 07:12 Andreas Klebinger <[hidden email]> wrote:
Hello devs,

I would appreciate feedback on the idea in
https://gitlab.haskell.org/ghc/ghc/merge_requests/934

Maps/Sets in GHC for the most part offer the same basic functionality
but their interfaces differ.
In order to make this easier to work with I propose using overloading
via IsSet/IsMap classes.

The goal is to make working with these data structures simpler by having
a uniform interface
when it comes to names and argument orders.

There are downsides, but to me they seem minor. Error messages can be
more confusing when one
get's the types wrong. We have to import the class to use it and the like.
However overall I think making code easier by not having to remember the
naming scheme + argument order
for the different possible instances would make this worthwhile.

But GHC isn't my project but one of the community so please voice your
opinion on the matter on the
merge request!

Cheers
Andreas
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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

Re: Overloaded names for Map/Set?

George Colpitts
In reply to this post by Andreas Klebinger
fwiw, I think this is a good idea

On Fri, May 24, 2019 at 11:12 AM Andreas Klebinger <[hidden email]> wrote:
Hello devs,

I would appreciate feedback on the idea in
https://gitlab.haskell.org/ghc/ghc/merge_requests/934

Maps/Sets in GHC for the most part offer the same basic functionality
but their interfaces differ.
In order to make this easier to work with I propose using overloading
via IsSet/IsMap classes.

The goal is to make working with these data structures simpler by having
a uniform interface
when it comes to names and argument orders.

There are downsides, but to me they seem minor. Error messages can be
more confusing when one
get's the types wrong. We have to import the class to use it and the like.
However overall I think making code easier by not having to remember the
naming scheme + argument order
for the different possible instances would make this worthwhile.

But GHC isn't my project but one of the community so please voice your
opinion on the matter on the
merge request!

Cheers
Andreas
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs