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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
