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 <silent.leaf0@gmail.com> 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?


Le mercredi 1 juin 2016, Alex Rozenshteyn <rpglover64@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@gmail.com> wrote:
>>
>> Map and Set are not.
>>
>> On 01/06/2016 8:57 AM, "Jeffrey Brown" <jeffbrown.the@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@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@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@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