[comp.object] "Ad Hoc Polymorphism" -- I'm Quoting Someone Else

eberard@ajpo.sei.cmu.edu (Edward Berard) (01/09/90)

Jim Adcock has admonished me as follows:

	"Can you please choose some other descriptor rather than "ad
	hoc polymorphism" ???  This term is not descriptive, is being
	applied to a technique that is certainly *not* "ad hoc," and
	sounds like it is intended to be prejudicial terminology --
	which I'm sure was not your intent!"

I try not to invent terminology -- there is too much already. So, I
try to use terms as I found them. Initially, all I had to worry about
was (plain) "polymorphism." However, it quickly became apparent that
there were several distinct forms of polymorphism. So I looked for
terminology which seemed to be already in use to describe the different
forms. 

In the August 1989 issue of _Computer__Language_ (Vol. 6, No. 8),
there is an article by Richard P. Gabriel, titled "Using the Common
LISP Object System." The following paragraph is from page 77 of that
article: 

	"CLOS uses a technique called the generic function approach.
	Common LISP -- and most LISPs -- support ad hoc polymorphism.
	In ordinary polymorphism, the definition of an operation is
	such that it is insensitive to the types of arguments passed
	to it. In ad hoc polymorphism, the types of the arguments are
	examined and appropriate code executed."

If you recognize this type of polymorphism as having a different name,
and can cite two, or more, earlier references, I will consider using
a different name. (Heck! I'll even take _one_ earlier reference. ;-))

				-- Ed Berard
				   (301) 353-9652

mjl@cs.rit.edu (01/09/90)

In article <646@ajpo.sei.cmu.edu> eberard@ajpo.sei.cmu.edu (Edward Berard) writes:
>Jim Adcock has admonished me as follows:
>
>	"Can you please choose some other descriptor rather than "ad
>	hoc polymorphism" ???  This term is not descriptive, is being
>	applied to a technique that is certainly *not* "ad hoc," and
>	sounds like it is intended to be prejudicial terminology --
>	which I'm sure was not your intent!"
>
>If you recognize this type of polymorphism as having a different name,
>and can cite two, or more, earlier references, I will consider using
>a different name. (Heck! I'll even take _one_ earlier reference. ;-))

I doubt such a reference will be found, as the original use of the
phrase "ad-hoc polymorphism" is from Christopher Strachey ("Fundamental
concepts in programming languages." Lecture Notes for the International
School in Computer Programming, Copenhagen, Aug. 1967).  Note the date:
well before the first Smalltalk system, and coterminal with the
introduction of Simula.  I don't have the original handy, but I do have
a second hand source, the paper "On Understanding Types, Data
Abstraction, and Polymorphism", by Peter Wegner and Luca Cardelli, ACM
Computing Surveys, December 1985.  To quote from this paper (p. 475):

  Strachey distinguished, informally, between two major kinds of
  polymorphism.  *Parametric polymorphism* is obtained when a function
  works uniformly on a range of types; these types normally exhibit
  some common structure.  *Ad-hoc polymorphism* is obtained when a
  function works, or appears to work, on several different types (which
  may not exhibit a common structure) and may behave in unrelated ways
  for each type.

[If Strachey was not using ad-hoc polymorphism as a pejorative, he
certainly considered such polymorphism unseemly :-) mjl]

Wegner and Cardelli then define a new form of polymorphism, *inclusion
polymorphism*, to handle inheritance.  They group both parametric
and inclusion polymorphism under a superclass universal polymorphism,
because they both achieve a uniform type structure.  By way of
contrast, coercion and overloading are forms of non-uniform, ad-hoc
polymorphism. [A classic example is overloading "+" on strings to
mean catenation - mjl]

I strongly recommend this paper to those interested in a deeper
appreciation of the issues surrounding the notion of "type".

Mike Lutz
Rochester Institute of Technology
mjl@cs.rit.edu
rutgers!rochester!rit!mjl

Mike Lutz	Rochester Institute of Technology, Rochester NY
UUCP:		{rutgers,cornell}!rochester!rit!mjl
INTERNET:	mjlics@ultb.isc.rit.edu

norman@a.cs.okstate.edu (Norman Graham) (01/10/90)

From article <646@ajpo.sei.cmu.edu>, by eberard@ajpo.sei.cmu.edu (Edward Berard):
> Jim Adcock has admonished me as follows:
> 
> 	"Can you please choose some other descriptor rather than "ad
> 	hoc polymorphism" ???  [...]
> 
> I try not to invent terminology -- there is too much already. So, I
> try to use terms as I found them. [...]
> 
> If you recognize this type of polymorphism as having a different name,
> and can cite two, or more, earlier references, I will consider using
> a different name. (Heck! I'll even take _one_ earlier reference. ;-))

Please don't change your terminology. As early as 1967, Christopher
Strachey [1] made a distinction between ad-hoc polymorphism and 
parametric polymorphism. The standard vocabulary for polymorphism
is recorded in Cardelli and Wegner's execent article on types, abstraction,
and polymorphism [2]. The polymorphic hierarchy is as follows:

                                  +--- parametric
                +--- universal ---|
                |                 +--- inclusion
polymorphism ---|
                |                 +--- overloading
                +--- ad hoc ------|
                                  +--- coercion

[Another semi-related article is Danforth and Tomlinson's article [3]
on types and oop.]

Cheers,
Norm

[1] Christopher Strachey. Fundamental concepts in programming languages. 
    Lecture notes for International Summer School in Computer Programming,
    Copenhagen, August, 1967.
[2] Luca Cardelli and Peter Wegner. On understanding types, data
    abstraction, and polymorphism. "ACM Computing Surveys," Vol. 17,
    No. 4, December 1985, pp. 471-522.
[3] Scott Danforth and Chris Tomlinson. Type theories and object-oriented
    programming. "ACM Computing Surveys," Vol. 20, No. 1, March 1988,
    pp. 29-72.
-- 
Norman Graham                            Oklahoma State University
  Internet:  norman@a.cs.okstate.edu     Computing and Information Sciences
      UUCP:  {cbosgd, rutgers}           219 Mathematical Sciences Building
              !okstate!norman            Stillwater, OK  USA  74078-0599

jimad@microsoft.UUCP (JAMES ADCOCK) (01/10/90)

>	"CLOS uses a technique called the generic function approach.
>	Common LISP -- and most LISPs -- support ad hoc polymorphism.
>	In ordinary polymorphism, the definition of an operation is
>	such that it is insensitive to the types of arguments passed
>	to it. In ad hoc polymorphism, the types of the arguments are
>	examined and appropriate code executed."

There are at least three different ways to generate code for polymorphism.
Like early Smalltalk systems, you can try to generate code that handles
all possible cases of type equally, or like more recent Smalltalk systems
you can try to determine all or some of the type information at compile
time, and thus generate faster code -- possibly generating several versions
of code to handle the most likely cases of types that may appear at run time.
Or some compilers/languages attempt to determine most or all type info at
compile time, invoking totally different routines depending on the runtime
examination of the types involved.  In that one language can be compiled
using different strategies for code generation by different compilers,
--and that interpreters for a language might take a totally different
approach to code generation that compilers for the same language -- isn't
it silly to try to define language features in terms of code generated?

-- In any case, repeating the prejudicial naming conventions of
previous authors seems to me to be a variation of a discredited
defense: "I was only following [orders][precedence]."

We need to be able to speak clearly, and without prejudice when comparing
features of one language from the next.  And we need to clearly differentiate
the features of languages from the features of compilers and code generators
-- except to the extent one can show a particular language feature *demands*
such-and-such code be generated.  [Recent articals comparing inheritence to
delegation, are good examples]  Prejudicial terminology only serves to confuse
the issue, and to further isolate programmers in their favorite language camps.

pallas@Neon.Stanford.EDU (Joe Pallas) (01/10/90)

In article <646@ajpo.sei.cmu.edu> eberard@ajpo.sei.cmu.edu (Edward
Berard) writes:

>If you recognize this type of polymorphism as having a different name,
>and can cite two, or more, earlier references, I will consider using
>a different name. (Heck! I'll even take _one_ earlier reference. ;-))

On the contrary, this is exactly the usage that the community at large
uses.  An excellent reference is Cardelli & Wegner's ``On
Understanding Types, Data Abstraction, and Polymorphism'' in Computing
Surveys 17:4 (Dec. 1985).  They classify polymorphism as either ad hoc
(applying to a finite number of unrelated types) or universal
(applying to an infinite number of related types).  Ad hoc
polymorphism includes overloading and coercion. 

Universal polymorphism is further classified as parametric or
inclusion polymorphism.  Inclusion polymorphism is the important one
for OOP---it's the case in which ``an object can be viewed as
belonging to many different classes that need not be disjoint.''  This
happens with inheritance: when an X is a Y, function f:X->Z can take
parameters of type Y.

Ed's article suggested that parametric polymorphism is distinct from
what he called ``general polymorphism'' (same code for any type), but
Cardelli & Wegner don't make that distinction.  They describe both
parametric and inclusion polymorphism as using the same code for any
type.  (Arguments on this point necessarily revolve around the
definition of ``same code''.  They treat parametric/generic code as
``same'' for different parameters.)

Note that a single system can have more than one kind of polymorphism.
Most modern languages support both kinds of ad hoc polymorphism
(overloading and implicit coercions), at least for built-in arithmetic
types.  Ada adds parametric polymorphism (generics).  C++ adds
inclusion polymorphism (derived classes).  Eiffel adds both parametric
and inclusion polymorphism.  I think CLOS generic functions can even
be overloaded, parametric, and inclusive all at once.

joe

srinivas@ics.uci.edu (Yellamraju Srinivas) (01/10/90)

eberard@ajpo.sei.cmu.edu (Edward Berard) writes:

>If you recognize this type of polymorphism as having a different name,
>and can cite two, or more, earlier references, I will consider using
>a different name. (Heck! I'll even take _one_ earlier reference. ;-))


Here is a quote from J. C. Reynolds [1]:

    The concept of polymorphism was first recognized by Strachey [2],
    who distinguished between "parametric" and "ad hoc" polymorphism.
    Intuitively, a parametric polymorphic function is one that behaves
    the same way for all types, while an ad hoc polymorphic function
    may have unrelated meanings for different tyupes. For example, an
    ad hoc function might add integers, "or" Boolean values, and
    compose functions.

"Ad hoc" polymorphism is another name for overloading, i.e, the use
the same syntactic symbol to denote different functions depending on
the context. The concept of "parametric polymorphism" is an intuitive
one.  Recently, there have attempts to characterize this notion
formally [3][4], by using the precise concepts of "functorial" and
"natural" in category theory.

[1] J.C.Reynolds, "Types, Abstraction and Parametric Polymorphism",
    Information Processing '83, Ed. R.E.A.Mason, North-Holland, 1983.
[2] C. Strachey, "Fundamental Concepts in Programming Languages",
    Lecture Notes, International Summer School in Computer
    Programming, Copenhagen, August 1967.
[3] E.S.Bainbridge, P.J.Freyd, A.Scedrov, and P.J.Scott, "Functorial
    Polymorphism", in "Logical Foundations of Functional Programming",
    Proceedings, Austin, 1987, Ed. G. Huet, Addison-Wesley, in press.
[4] P.J.Freyd, J.Y.Girard, A.Scedrov, and P.J.Scott, "Semantic
    Parametricity in Polymorphic Lambda Calculus", in Proceedings,
    "Logic in Computer Science '88", Edinburgh, IEEE Computer Society
    Press, 1988.

--
Y V Srinivas
Dept of ICS, University of California, Irvine, CA 92717

grover%brahmand@Sun.COM (Vinod Grover) (01/10/90)

In article <646@ajpo.sei.cmu.edu> eberard@ajpo.sei.cmu.edu (Edward Berard) writes:
>Jim Adcock has admonished me as follows:
>
>	"Can you please choose some other descriptor rather than "ad
>	hoc polymorphism" ???  This term is not descriptive, is being
>	applied to a technique that is certainly *not* "ad hoc," and
>	sounds like it is intended to be prejudicial terminology --
>	which I'm sure was not your intent!"

Some authors term the Ada-style overloading of functions as "ad-hoc
polymorphism". I do not have a reference handy, but I remember a paper by
Burstall and Lampson on Pebble mention this. 


Vinod Grover

dbm@alice.UUCP (David MacQueen) (01/10/90)

The phrase "ad hoc polymorphism" was coined by Christopher Strachey in
course notes for a Copenhagen summer school in 1967.  He used the phrase
to refer to conventional overloading of operator names in contrast to
"parametric polymorphism", by which he meant roughly the type of polymorphism
used in ML and the second order lambda calculus.