Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!caen!news.cs.indiana.edu!arizona.edu!arizona!gudeman
From: gudeman@cs.arizona.edu (David Gudeman)
Newsgroups: comp.lang.misc
Subject: Re: Runtime Polymorphism -- To Have and Have Not
Message-ID: <607@optima.cs.arizona.edu>
Date: 12 Mar 91 16:59:40 GMT
Sender: news@cs.arizona.edu
Lines: 62

In article  <1991Mar11.114638.2220@tukki.jyu.fi> Markku Sakkinen writes:
]In article <595@optima.cs.arizona.edu> gudeman@cs.arizona.edu (David Gudeman) writes:
]
]Many proponents of dynamic typing in turn seem to be obsessed out of
]proportion by completely polymorphic lists and the like,
]which have very limited usefulness.

It isn't that completely polymorphic lists are so useful, in fact
they are rarely used.  What is important is the ability to change the
types that can go in the list without making pervasive changes to the
program -- and without having to look for a declaration for the list.

]>... To compare two values you have to
]>write code to check the type and do the right thing based on the type.
]>You have to (in general) write seperate code for every type that is
]>used in the program.
]
]Even if you are not "hampered" by static typing, you have to do pretty
]much the same things in order to handle a totally polymorphic collection
]sensibly.  There are hardly any operations that are applicable to all
]possible types of objects.  If you want to compare two arbitrary objects,
]you just have to look at their types to see whether the comparison
]makes any sense.

No you don't.  Languages with dynamic typing have built-in operators
that work on all types as determined at runtime (that's why I started
with the term "runtime polymorphism").  I can write completely generic
routines to compare, copy, print, etc., all the elements of a generic
list.  And completely generic lists are rare anyway.  As you suggest,
there the elements of the list are usually restricted to some set of
types with even more operations in common.  You can just assume that
the list has elements of one of the correct types, and if that
assumption proves wrong, you get a runtime error message.

]It is not a good idea to prohibit static typing totally, as Gudeman
]seems to suggest.

You must not have read part 2.  There I give my preference, one that
allows both dynamic and static typing.

]2. Several languages even allow a type definition of "any" (i.e.
]   a totally polymorphic variable) whenever that is really wanted.
]   I think Eiffel (on which Sommarskog gave an example) currently
]   has this facility.

These features do not give dynamic typing.  They only give built-in
tagged union types, and the only static typing problem they solve is
that you don't have to change the declarations of a structure when you
change the types of elements.  They still require you to check the
types of elements before you do anything with them.

]...Neither do I share Gudeman's belief that testing will quickly
]and easily reveal all (typing) errors.

This is something that I have discovered from experience, not
something that I have tried to intuit.  I doubt anyone with serious
experience with dynamically typed languages would take these
complaints about type errors seriously.  They just aren't a problem.
--
					David Gudeman
gudeman@cs.arizona.edu
noao!arizona!gudeman