From: chambers@klamath.cs.washington.edu (Craig Chambers)
Newsgroups: comp.object,comp.lang.functional
Subject: ad hoc vs. parametric polymorphism (Was Re: comparing object-oriented platforms)
Date: 7 Oct 92 20:09:03 GMT
Article-I.D.: beaver.1992Oct7.200903.19397
Reply-To: chambers@cs.washington.edu
Organization: University of Washington

In article <1992Oct6.190729.24367@ucc.su.OZ.AU>, maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
|> In article <1992Oct6.003602.21078@beaver.cs.washington.edu> chambers@cs.washington.edu writes:
|> >In article <TMB.92Oct4182305@arolla.idiap.ch>, tmb@arolla.idiap.ch (Thomas M. Breuel) writes:
|> >|> OO-style polymorphism is more restrictive than Milner-style
|> >|> polymorphism, and also too restrictive for my tastes in the presence
|> >|> of a static type checker.
|> >
|> >Ad hoc ("OO-style") polymorphism is not more restrictive than
|> >parametric ("Milner-style") polymorphism; the two are incomparable in
|> >expressive power.  Certainly things like arrays of mixed integers,
|> >rationals, and floats cannot be statically-typed in ML.  
|> 
|> 	Its very difficult for me to see how you can use
|> an array of polymorphic numbers to *do* anything. I dont
|> believe numbers can be characterised as "OO-style" objects.

I think numbers are a fine example of ad hoc polymorphism.  There are
a number of different possible representations for numbers, but these
representations share a common protocol.  They may not have mutable
state, but I for one don't consider mutable state the key idea behind
OO.

In a purely OO language, new numeric representations can be added to
the system by programmers, as long as they continue to support the
expected protocol.  This is not the case in languages such as SML.
Haskell is better at this with its type classes.

|> 	For example, to test if such an array is sorted,
|> you need a comparison routine. One way to write such a
|> routine is to convert each number to a fixed predefined
|> numeric type (say double float), and this method
|> is indeed polymorphic (that is, the conversion routine is).

Blech.  Both slow and inaccurate.  But this is a comment on the
approach, not language support.  This approach could be implemented in
languages with ad hoc polymorphism just fine.  Again, in SML only a
fixed set of numbers would support this built-in polymorphic
conversion routine.  In Haskell user-defined numbers could be added to
the system, but arrays still would be restricted to containing only
one representation of number.

|> 	I dont believe it can be done without the predefined
|> universal numeric type. Of course, if you fix in advance
|> the number classes to say Integer, Rational, Float, then you can
|> write 9 comparison routines to do the job and dispatch
|> to the correct one, but this isnt polymorphism in my books,
|> or rather, it isnt object oriented. The reason of course
|> is that to add a new type Double you have to know the types
|> you already have---they are coupled when OO requires
|> each type be self-contained (encapsulated).

For binary operations where the algorithm depends on the
implementation of more than one argument, some form of multiple
dispatching, either through multi-methods or simulated through double
dispatching, would be used.  This may require the implementor to know
in advance the various kinds of numbers involved in order to compare
them, but that's a necessary part of the problem.  OO won't magically
make this disappear, but the need to write e.g. 9 comparison routines
would be present in a non-OO solution, too.  OO doesn't prohibit such
situations.

As far as encapsulation of objects goes, I'm working on a
multi-method-based OO language named Cecil that attempts to keep
objects encapsulated in the presence of multi-methods.  The basic idea
is that a multi-method is inside the encapsulation boundaries of each
of the classes on which it specializes.  Classes don't have to be
completely exposed to all objects to support multi-methods (as in 
CLOS).  Instead, the internals of classes are only exposed to methods
that specialize on them.  These ideas are described in more detail in
my ECOOP'92 paper.

-- Craig Chambers