why is there no typeclass common to all containers?

Silent Leaf

31 May 2016 31 May '16

6:18 p.m.

All in the title. I haven't used them much, but I saw Map or Vector types were forcing the user to use qualified functions unless you want nameclash with the more basic, typically list-oriented functions. So, why not have a massive, general purpose interface so the type only can separate between containers --which would allow for cross-container polymorphism, i suppose, more easily, even though it's not necessarily the most widespread need. So, do i miss something? Is there in fact a class of that kind? If so why not? Thanks in advance! :)

Attachments:

attachment.html (text/html — 563 bytes)

Show replies by date

Silent Leaf

31 May 31 May

6:26 p.m.

...

All in the title. I haven't used them much, but I saw Map or Vector types were forcing the user to use qualified functions unless you want nameclash with the more basic, typically list-oriented functions. So, why not have a massive, general purpose interface so the type only can separate between containers --which would allow for cross-container

In fact it all comes down to trying to add partially a feature absent from the Haskell language, which is the ability to distinguish values both on name *and* on type --thus allowing two variables of the same name if they have different types. Honestly i don't see the drawback of that name system, but i guess there must be one otherwise it'd have been chosen by default instead of the typeblind current name system. Le mercredi 1 juin 2016, Silent Leaf a écrit : polymorphism, i suppose, more easily, even though it's not necessarily the most widespread need.

...

So, do i miss something? Is there in fact a class of that kind? If so why not? Thanks in advance! :)

Jeffrey Brown

6:57 p.m.

In Haskell typeclasses are based on what you want to do with something. If, for instance, you want to be able to map over a container, you can make it an instance of class Functor -- which all the standard containers (List, Map, Set, Tree, Maybe ...) already are. On Tue, May 31, 2016 at 3:26 PM, Silent Leaf wrote:

...

In fact it all comes down to trying to add partially a feature absent from the Haskell language, which is the ability to distinguish values both on name *and* on type --thus allowing two variables of the same name if they have different types. Honestly i don't see the drawback of that name system, but i guess there must be one otherwise it'd have been chosen by default instead of the typeblind current name system.

...
All in the title. I haven't used them much, but I saw Map or Vector types were forcing the user to use qualified functions unless you want nameclash with the more basic, typically list-oriented functions. So, why not have a massive, general purpose interface so the type only can separate between containers --which would allow for cross-container

Le mercredi 1 juin 2016, Silent Leaf a écrit : polymorphism, i suppose, more easily, even though it's not necessarily the most widespread need.

...
So, do i miss something? Is there in fact a class of that kind? If so why not? Thanks in advance! :)

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

-- Jeffrey Benjamin Brown

Silent Leaf

7:39 p.m.

...

In Haskell typeclasses are based on what you want to do with something. If, for instance, you want to be able to map over a container, you can make it an instance of class Functor -- which all the standard containers (List, Map, Set, Tree, Maybe ...) already are. On Tue, May 31, 2016 at 3:26 PM, Silent Leaf wrote:

...
In fact it all comes down to trying to add partially a feature absent

from the Haskell language, which is the ability to distinguish values both on name *and* on type --thus allowing two variables of the same name if

...

...
Honestly i don't see the drawback of that name system, but i guess there must be one otherwise it'd have been chosen by default instead of the typeblind current name system.

Le mercredi 1 juin 2016, Silent Leaf a écrit :

...
All in the title. I haven't used them much, but I saw Map or Vector types were forcing the user to use qualified functions unless you want nameclash with the more basic, typically list-oriented functions. So, why not have a massive, general purpose interface so the type only can separate between containers --which would allow for cross-container

sure i know that, but what about sorting, or getting an element through a certain way (i bet there's a way to isolate the way the getting is done)? deleting one, etc. those are common operations but each function for each type requires its special name and namespace because each type needs its own functions because there's to my knowledge no typeclass for typically container oriented overlodable and -loaded functions (OTHER than the functor-app-monad triad and any other typeclass already existing), that is, any other container-related function that has several equivalents across types, and that isn't already in any typeclass. i thought it was implicitly obvious in my question. in fact, way beyond the limited scope of container, i wonder why function overloading isn't chosen every time there's a common operation across types (and i mean every time). that is, as you said, every time we want to do something similar but for different types, differently. Le mercredi 1 juin 2016, Jeffrey Brown a écrit : they have different types. polymorphism, i suppose, more easily, even though it's not necessarily the most widespread need.

...

...
...
So, do i miss something? Is there in fact a class of that kind? If so why not? Thanks in advance! :)

Beginners mailing list Beginners@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners

-- Jeffrey Benjamin Brown

Simon Jakobi

8:55 p.m.

There are several packages that define typeclasses for containers and, in particular, "map-like" things: * keys (no construction, no insertion) * Data.Containers from the mono-traversable package * EdisonAPI * https://github.com/commercialhaskell/jump (still in the works) Another somewhat related package is focus, which defines a common abstraction for various operations on a key-value pair in a map.

Tony Morris

1 Jun 1 Jun

1:14 a.m.

Map and Set are not. On 01/06/2016 8:57 AM, "Jeffrey Brown" wrote:

...

In Haskell typeclasses are based on what you want to do with something. If, for instance, you want to be able to map over a container, you can make it an instance of class Functor -- which all the standard containers (List, Map, Set, Tree, Maybe ...) already are.

On Tue, May 31, 2016 at 3:26 PM, Silent Leaf wrote:

...
In fact it all comes down to trying to add partially a feature absent from the Haskell language, which is the ability to distinguish values both on name *and* on type --thus allowing two variables of the same name if they have different types. Honestly i don't see the drawback of that name system, but i guess there must be one otherwise it'd have been chosen by default instead of the typeblind current name system.

...
All in the title. I haven't used them much, but I saw Map or Vector types were forcing the user to use qualified functions unless you want nameclash with the more basic, typically list-oriented functions. So, why not have a massive, general purpose interface so the type only can separate between containers --which would allow for cross-container

Le mercredi 1 juin 2016, Silent Leaf a écrit : polymorphism, i suppose, more easily, even though it's not necessarily the most widespread need.

...
So, do i miss something? Is there in fact a class of that kind? If so why not? Thanks in advance! :)

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

-- Jeffrey Benjamin Brown

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

Alex Rozenshteyn

12:35 p.m.

Map is (you map over the values, not the keys). On Wed, Jun 1, 2016 at 1:14 AM Tony Morris wrote:

...

Map and Set are not. On 01/06/2016 8:57 AM, "Jeffrey Brown" wrote:

...
In Haskell typeclasses are based on what you want to do with something. If, for instance, you want to be able to map over a container, you can make it an instance of class Functor -- which all the standard containers (List, Map, Set, Tree, Maybe ...) already are.

On Tue, May 31, 2016 at 3:26 PM, Silent Leaf wrote:

...
In fact it all comes down to trying to add partially a feature absent from the Haskell language, which is the ability to distinguish values both on name *and* on type --thus allowing two variables of the same name if they have different types. Honestly i don't see the drawback of that name system, but i guess there must be one otherwise it'd have been chosen by default instead of the typeblind current name system.

...
All in the title. I haven't used them much, but I saw Map or Vector types were forcing the user to use qualified functions unless you want nameclash with the more basic, typically list-oriented functions. So, why not have a massive, general purpose interface so the type only can separate between containers --which would allow for cross-container

Le mercredi 1 juin 2016, Silent Leaf a écrit : polymorphism, i suppose, more easily, even though it's not necessarily the most widespread need.

...
So, do i miss something? Is there in fact a class of that kind? If so why not? Thanks in advance! :)

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

-- Jeffrey Benjamin Brown

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

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

Silent Leaf

1:18 p.m.

...

Map is (you map over the values, not the keys).

On Wed, Jun 1, 2016 at 1:14 AM Tony Morris wrote:

...
Map and Set are not.

On 01/06/2016 8:57 AM, "Jeffrey Brown" wrote:

...
In Haskell typeclasses are based on what you want to do with something.

If, for instance, you want to be able to map over a container, you can make it an instance of class Functor -- which all the standard containers (List, Map, Set, Tree, Maybe ...) already are.

...
...
On Tue, May 31, 2016 at 3:26 PM, Silent Leaf wrote:

...
In fact it all comes down to trying to add partially a feature absent

from the Haskell language, which is the ability to distinguish values both on name *and* on type --thus allowing two variables of the same name if

...

...
...
...
Honestly i don't see the drawback of that name system, but i guess

map and set are not what? I didn't get it. That's cool, I'll look into it! As for why Haskell doesn't allow natural overloading of any function name merely by choosing another name, does anyone know? Le mercredi 1 juin 2016, Alex Rozenshteyn a écrit : they have different types. there must be one otherwise it'd have been chosen by default instead of the typeblind current name system.

...

...
...
...
Le mercredi 1 juin 2016, Silent Leaf a écrit :

...
All in the title. I haven't used them much, but I saw Map or Vector

types were forcing the user to use qualified functions unless you want nameclash with the more basic, typically list-oriented functions.

...
...
So, why not have a massive, general purpose interface so the type only can separate between containers --which would allow for cross-container polymorphism, i suppose, more easily, even though it's not necessarily the most widespread need. So, do i miss something? Is there in fact a class of that kind? If so why not? Thanks in advance! :)

Beginners mailing list Beginners@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners

-- Jeffrey Benjamin Brown _______________________________________________ Beginners mailing list Beginners@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners

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

Peter Hall

3 Jun 3 Jun

6:40 a.m.

...

As for why Haskell doesn't allow natural overloading of any function name merely by choosing another name, does anyone know?

Haskell requires that overloaded functions are part of a typeclass. This isn't a big requirement - you can easily make any type into an instance of a new typeclass. The reason why this is important is that it ensures that the meaning and intent of the function are the same, not just a coincidental naming collision. Peter On 1 June 2016 at 18:18, Silent Leaf wrote:

...

map and set are not what? I didn't get it.

That's cool, I'll look into it! As for why Haskell doesn't allow natural overloading of any function name merely by choosing another name, does anyone know?

...
Map is (you map over the values, not the keys).

On Wed, Jun 1, 2016 at 1:14 AM Tony Morris wrote:

...
Map and Set are not.

On 01/06/2016 8:57 AM, "Jeffrey Brown" wrote:

...
In Haskell typeclasses are based on what you want to do with

something. If, for instance, you want to be able to map over a container, you can make it an instance of class Functor -- which all the standard containers (List, Map, Set, Tree, Maybe ...) already are.

...
...
On Tue, May 31, 2016 at 3:26 PM, Silent Leaf wrote:

...
In fact it all comes down to trying to add partially a feature absent

from the Haskell language, which is the ability to distinguish values both on name *and* on type --thus allowing two variables of the same name if

...
...
...
...
Honestly i don't see the drawback of that name system, but i guess

Le mercredi 1 juin 2016, Alex Rozenshteyn a écrit : they have different types. there must be one otherwise it'd have been chosen by default instead of the typeblind current name system.

...
...
...
...
Le mercredi 1 juin 2016, Silent Leaf a

écrit :

...
...
All in the title. I haven't used them much, but I saw Map or Vector types were forcing the user to use qualified functions unless you want nameclash with the more basic, typically list-oriented functions. So, why not have a massive, general purpose interface so the type only can separate between containers --which would allow for cross-container polymorphism, i suppose, more easily, even though it's not necessarily the most widespread need. So, do i miss something? Is there in fact a class of that kind? If so why not? Thanks in advance! :)

Beginners mailing list Beginners@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners

-- Jeffrey Benjamin Brown _______________________________________________ Beginners mailing list Beginners@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners

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

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

Silent Leaf

1 Jun 1 Jun

1:39 p.m.

...

Map is (you map over the values, not the keys).

On Wed, Jun 1, 2016 at 1:14 AM Tony Morris wrote:

...
Map and Set are not.

On 01/06/2016 8:57 AM, "Jeffrey Brown" wrote:

...
In Haskell typeclasses are based on what you want to do with something.

If, for instance, you want to be able to map over a container, you can make it an instance of class Functor -- which all the standard containers (List, Map, Set, Tree, Maybe ...) already are.

...
...
On Tue, May 31, 2016 at 3:26 PM, Silent Leaf wrote:

...
In fact it all comes down to trying to add partially a feature absent

from the Haskell language, which is the ability to distinguish values both on name *and* on type --thus allowing two variables of the same name if

...

...
...
...
Honestly i don't see the drawback of that name system, but i guess

I happen to have gotten my answer somewhere else (as for why values aren't overloadable as soon as you change the type of it). Indeed it does seem very useful to control name overloading by using typeclasses, which aside from grouping several overloadable variables together (so they can always use each other without fearing for the instance for say "mempty" wouldn't have been made when the one for "mappend" would have been), has the advantage to force the overloading instances to obey to some pattern (instead of accepting a (+) value which, say, does the same than (!!)) given in advance, especially they are parameterized over only one type (barring use of some extensions of the language). Le mercredi 1 juin 2016, Alex Rozenshteyn a écrit : they have different types. there must be one otherwise it'd have been chosen by default instead of the typeblind current name system.

...

...
...
...
Le mercredi 1 juin 2016, Silent Leaf a écrit :

...
All in the title. I haven't used them much, but I saw Map or Vector

types were forcing the user to use qualified functions unless you want nameclash with the more basic, typically list-oriented functions.

...
...
So, why not have a massive, general purpose interface so the type only can separate between containers --which would allow for cross-container polymorphism, i suppose, more easily, even though it's not necessarily the most widespread need. So, do i miss something? Is there in fact a class of that kind? If so why not? Thanks in advance! :)

Beginners mailing list Beginners@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners

-- Jeffrey Benjamin Brown _______________________________________________ Beginners mailing list Beginners@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners

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

3272

Age (days ago)

3275

Last active (days ago)

List overview

Download

9 comments

6 participants

participants (6)

Alex Rozenshteyn
Jeffrey Brown
Peter Hall
Silent Leaf
Simon Jakobi
Tony Morris

why is there no typeclass common to all containers?

tags

participants (6)