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).<br>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).<br><br><br>Le mercredi 1 juin 2016, Alex Rozenshteyn <<a href="mailto:rpglover64@gmail.com">rpglover64@gmail.com</a>> a écrit :<br>> Map is (you map over the values, not the keys).<br>><br>> On Wed, Jun 1, 2016 at 1:14 AM Tony Morris <<a href="mailto:tonymorris@gmail.com">tonymorris@gmail.com</a>> wrote:<br>>><br>>> Map and Set are not.<br>>><br>>> On 01/06/2016 8:57 AM, "Jeffrey Brown" <<a href="mailto:jeffbrown.the@gmail.com">jeffbrown.the@gmail.com</a>> wrote:<br>>>><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<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>>> 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>>