Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!fuug!news.funet.fi!tukki.jyu.fi!sakkinen
From: sakkinen@tukki.jyu.fi (Markku Sakkinen)
Newsgroups: comp.lang.misc
Subject: Re: Runtime Polymorphism -- To Have and Have Not
Message-ID: <1991Mar11.114638.2220@tukki.jyu.fi>
Date: 11 Mar 91 11:46:38 GMT
References: <595@optima.cs.arizona.edu>
Reply-To: sakkinen@jytko.jyu.fi (Markku Sakkinen)
Organization: University of Jyvaskyla, Finland
Lines: 74

In article <595@optima.cs.arizona.edu> gudeman@cs.arizona.edu (David Gudeman) writes:

[Quote from the very end of the posting:]
> [...] Type errors are a trivial concern that get blown way out of
>proportion by people who are used to statically typed languages and
>are looking for justifications not to learn and use better
>technologies.

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.

>In article  <2773@enea.se> Erland Sommarskog writes:
>] ...
> ...
>I prefer to spend the time writing experimental code.  After you have
>decided how to organize your data, the vast majority of time spent in
>declarations is trivial stuff that can (and should) be done by the
>computer.
>
>]What do you mean? OK, in Ada you have to write
>]
>]    PACKAGE Integer_list IS NEW Linked_list(integer);
>]    PACKAGE Array_list IS NEW Linked_list(Array_type);
>
>]and then declare each list you need. But you don't have to rewrite
>]the list package for any type that you might think of.
>
>You aren't getting the same functionality that dynamic typing gives.
>To get that functionality you would have to declare a tagged union of
>every type in the program, and for each list function that deals with
>list values you have to do the right thing with the member of the list
>depending on it's actual type.  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.

It is not a good idea to prohibit static typing totally, as Gudeman
seems to suggest.  Many languages that have static typing available
actually allow various degrees of dynamic typing:

1. Object-oriented languages typically allow the type of a variable
   to be defined as a given class or any subclass of it.  This is much
   more often what is really needed than unbounded polymorphism.

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.

I think Objective-C, which originally was based on totally dynamic
typing like Smalltalk, currently allows static type declarations
of any or all variables.  So there seems to be a convergence
to "the best of both worlds" from both sides.

I certainly fail to see that preventing a programmer from declaring
any static type information would be "better technology".
Neither do I share Gudeman's belief that testing will quickly
and easily reveal all (typing) errors.

Markku Sakkinen
Department of Computer Science and Information Systems
University of Jyvaskyla (a's with umlauts)
PL 35
SF-40351 Jyvaskyla (umlauts again)
Finland
          SAKKINEN@FINJYU.bitnet (alternative network address)