The discussion of overloading seems very abstract. The question is really how overloading interacts with other language features. For example, how does overloading interact with the module system? When you import a function from another module, do you need to specify a type as well as a name? I know there are plans for a new module system, what is the story there? Does overloading mean that you don't need MPTC? One of the nice things about type classes is they provide a nice way of grouping related functions. Arguably, with overloading, this work would be done by the module system. Is the module system powerful enough to support this? Does overloading mean that you don't need Existential types? Overloading would allow you to map a function over a list of various types (as in Java) and have the correct function be chosen for each type. (Are existential types part of an implementation of overloading?). Does a combination of overloading and TREX make 'data' statements obsolete? Does it mean a more consistent TREX syntax? How does overloading interact with operator precedence? Can you have: > (+)::String->String->String -- concatenate with precedence 5 > (+)::String->Int -> String -- concatenate with show(int) prec 5 > (*)::String->Int->String --copy string with precedence 4 > (*)::Int->String->String --copy string with precedence 6!! So that: 2 * "foo" + "bar" => "foofoobar" "foo" + "bar" * 2 => "foobarfoobar" "foo" * 2 + "bar" => "foo2bar" There is already ambiguity about operator precedence and modules? Now it seems much worse. If you have overloading and prefix and postfix directives, you end up with the ability to create very powerful domain specific languages. This power could be abused, but it could be very elegant. The interaction between polytypism and overloading seems particularly powerful because polytypic functions don't need to worry about namespace polution on function names. e.g. you don't have to create a HasSize class to create a generic 'size' function. But the syntax of derive and the polytypic extentions needs to be rethought in the presence of such features. Overloading also seems to have a very positive interaction with HDirect. Exposing object from overloading languages like CORBA and COM IDL in Haskell is really ugly because of the need to name mangle each variant of a function name. If we want Haskell to become a really useful scripting language for objects created in other languages, overloading seems like a requirement rather than an option. ---- There is a tradeoff between giving programmers a lot of power and guaranteeing language readability. My bias is towards the former, IF you have a good module/reuse system/framework. Program shortness can compensate a lot for poor coding style. -Alex- ___________________________________________________________________ S. Alexander Jacobson Shop.Com 1-212-697-0184 voice The Easiest Way To Shop
Re: View on true ad-hoc overloading.
S. Alexander Jacobson Thu, 20 May 1999 14:39:44 -0400 (Eastern Daylight Time)
- RE: View on true ad-hoc overloading. Brian Boutel
- Re: View on true ad-hoc overloading. Olaf Chitil
- Re: View on true ad-hoc overloading. Kevin Atkinson
- Re: View on true ad-hoc overloading. Hans Aberg
- RE: View on true ad-hoc overloading. Hans Aberg
- Re: View on true ad-hoc overloading. Jan de Wit
- Re: View on true ad-hoc overloading. Carlos Camarao de Figueiredo
- Re: View on true ad-hoc overloading. Jon . Fairbairn
- Re: View on true ad-hoc overloading. Hans Aberg
- RE: View on true ad-hoc overloading. Patrick Logan
- Re: View on true ad-hoc overloading. S. Alexander Jacobson
- Re: View on true ad-hoc overloading. Fergus Henderson
- Re: View on true ad-hoc overloading. Carlos Camarao de Figueiredo
- Re: View on true ad-hoc overloading. Fergus Henderson
- Re: View on true ad-hoc overloading. Patrick Logan
- Re: View on true ad-hoc overloading. Nigel Perry
- Re: View on true ad-hoc overloading. Fergus Henderson
- Re: View on true ad-hoc overloading. Fergus Henderson
- Re: View on true ad-hoc overloading. Fergus Henderson
- Re: View on true ad-hoc overloading. Kevin Atkinson
- Re: View on true ad-hoc overloading. Carlos Camarao de Figueiredo
