[Haskell-cafe] Re: Overloading functions based on arguments?

[Neil Mitchell]

Hi

> Chances are the program you're using to write your e-mails was written in
> C++ (or at least C), so don't knock it. :-)

Firefox (Javascript + C++) and Gmail (Python, so I think I read, no
doubt with C underneath somewhere). However, I am sat writing C++ at
the moment - which I think gives me the right to say that C++ is a
bloated and ugly language.

> In any case, no one has really addressed the original poster's question: No,
> "name overloading" is not possible in Haskell, and surprisingly, there are
> no blocking technical issues why this must be the case.

Name overloading is not possible currently. You could encode name
overloading as type classes internally and add the feature, but it
complicates type inference substantially. When I first started doing
Haskell I remember asking why we didn't have overloaded names. Now, I
ask the question why anyone could possibly want overloaded names.
Having drunk the functional kool-aid I've decided they are deeply
confusing :-)

Thanks

Neil

>
>> Hi
>>
>>> Table is a table of name-value pairs I want to substitute in a tree-like
>>> structure using:
>>>
>>> substitute :: Table -> Tree -> Tree
>>>
>>> For substituting a single name-value pair I want to define this utitlity
>>> routine so I don't have to construct a Table all the time in the user
>>> code:
>>>
>>> substitute :: String -> Value -> Tree -> Tree
>>
>> Why not:
>>
>> substituteValue :: String -> Value -> Tree -> Tree
>> substituteValue x y = substitute (table1 x y)
>>
>>> In the case I believe it would certainly be good to be able to name both
>>> functions the same, but I fear I can not do so?  There are languages
>>> where
>>> this is explicitelly allowed (e.g. C++ or Java), so I don't think it is
>>> such
>>> an unuseful or evil thing.
>>
>> Languages like C++ and Java allow mutable state, object-orientated
>> programming and require massively verbose code - all of which are
>> unuseful and evil :-)
>>
>> I think this is a case of trying to apply C++/Java thoughts on to
>> Haskell, you can map the concepts directly, but you really shouldn't.
>> Try writing multiple methods with many names, or simple utility
>> functions to convert between the cases, and it will go much nicer.
>>
>> Thanks
>>
>> Neil
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>