Brian Boutel writes:
>
> Programs for real world applications and programs which will be
> read by other people (or even by the author some time after writing
> them) must be correct, clear and unambiguous. Unambiguity implies
> not just that the compiler will not be confused, but that Joe
> Programmer will not be confused when reading a program to fix a bug
> or to modify it to reflect a change in requirements. To allow ad
> hoc overloading is to invite errors resulting from that kind of
> confusion. This is why Haskell, from the beginning, has had type
> classes but not arbitrary overloading.
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.
The HotDraw framework captures the essence of a MacDraw-like
application. (If anyone remembers MacDraw. Maybe I should say
"Visio"?) It handles input and incremental redisplay of graphical
objects on a canvas.
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.
It is possible to use Haskell for things like this via CORBA and
COM. How should this be done purely in Haskell? The way I have done it
is to build "ad hoc polymorphism" by hand using tuples of functions to
represent the methods of an object.
But I am no Haskell expert. Is there a way to do this kind of dynamic
programming-in-the-large today in Haskell that is not as error prone
as building tuples of functions?
--
Patrick Logan mailto:[EMAIL PROTECTED]
Voice 503-533-3365 Fax 503-629-8556
Gemstone Systems, Inc http://www.gemstone.com
