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.<br><br>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.<br><br>Le mercredi 1 juin 2016, Jeffrey Brown <<a href="mailto:jeffbrown.the@gmail.com">jeffbrown.the@gmail.com</a>> a écrit :<br>> 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.<br>> On Tue, May 31, 2016 at 3:26 PM, Silent Leaf <<a href="mailto:silent.leaf0@gmail.com">silent.leaf0@gmail.com</a>> wrote:<br>>><br>>> 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.<br>>> 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.<br>>><br>>> Le mercredi 1 juin 2016, Silent Leaf <<a href="mailto:silent.leaf0@gmail.com">silent.leaf0@gmail.com</a>> a écrit :<br>>> > 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.<br>>> > 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.<br>>> > So, do i miss something? Is there in fact a class of that kind? If so why not?<br>>> > Thanks in advance! :)<br>>> _______________________________________________<br>>> Beginners mailing list<br>>> <a href="mailto:Beginners@haskell.org">Beginners@haskell.org</a><br>>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners">http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners</a><br>>><br>><br>><br>><br>> --<br>> Jeffrey Benjamin Brown