On 20-May-1999, Patrick Logan <[EMAIL PROTECTED]> wrote:
> A problem that has not been fully resolved, AFAICT, in Haskell, is
> programming-in-the-large. What ad hoc polymorphism is good for in
> languages like Smalltalk, C++, etc. is to develop frameworks of large
> applications that can be extended by people the framework developers
> never meet. Consider the HotDraw framework as a small example.
...
> An application developer can make things like program inspectors, PERT
> chart schedulers, network problem analyzers, etc. by specializing
> HotDraw's "ad hoc" functions. Multiple developers can each contribute
> their own specializations to the same program, when conventions are
> established for how the ad hoc specializations should behave.
For that kind of thing, you should use type classes and, if need be,
existential types.
I don't think "ad hoc" overloading will help here. Note that the kind
of "ad hoc" overloading that we are contemplating (e.g. as implemented
in Mercury) does _not_ give you polymorphism. It just lets you use
the same name for two different things so long as the compiler can figure
out from the context which one you mean.
--
Fergus Henderson <[EMAIL PROTECTED]> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger [EMAIL PROTECTED] | -- the last words of T. S. Garp.
