Re: [Haskell-beginners] why is there no typeclass common to all containers?

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