I come from a mathematical background (in which it is quite common to "overload" function names and operators in particular), so from my point of view, the lack of name overloading is a wart on Haskell. That such a feature would complicate type inference is more a concern to an implementor, not to an end-user of Haskell like myself. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net | 877-376-2724 x 101 On Feb 13, 2009, at 10:16 AM, Neil Mitchell wrote:
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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe