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

[Silent Leaf]

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 <rpglover64 at gmail.com> a écrit :
> Map is (you map over the values, not the keys).
>
> On Wed, Jun 1, 2016 at 1:14 AM Tony Morris <tonymorris at gmail.com> wrote:
>>
>> Map and Set are not.
>>
>> On 01/06/2016 8:57 AM, "Jeffrey Brown" <jeffbrown.the at gmail.com> 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 <silent.leaf0 at gmail.com>
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.
>>>>
>>>> Le mercredi 1 juin 2016, Silent Leaf <silent.leaf0 at gmail.com> 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 at haskell.org
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>>>>
>>>
>>>
>>>
>>> --
>>> Jeffrey Benjamin Brown
>>> _______________________________________________
>>> Beginners mailing list
>>> Beginners at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>>>
>> _______________________________________________
>> Beginners mailing list
>> Beginners at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/beginners/attachments/20160601/333fb44d/attachment-0001.html>