Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!usc!wuarchive!m.cs.uiuc.edu!ibma0.cs.uiuc.edu!ux1.cso.uiuc.edu!uicbert.eecs.uic.edu!wilson
From: wilson@uicbert.eecs.uic.edu (Paul Wilson)
Newsgroups: comp.lang.misc
Subject: Static type inference? (was Re: Runtime Polymorphism)
Message-ID: <1991Mar5.180306.1561@uicbert.eecs.uic.edu>
Date: 5 Mar 91 18:03:06 GMT
References: <559@coatimundi.cs.arizona.edu> <2741@enea.se>
Organization: University of Illinois at Chicago
Lines: 55

sommar@enea.se (Erland Sommarskog) writes:

>Also sprach David Gudeman (gudeman@cs.arizona.edu):
>>There are several advantages to this.  First, it makes program
>>prototyping and developement much faster because declarations are
>>minimized.

>>Another advantage of runtime polymorphism is code generality.  You can
>>write generic procedures that work on many data types (as long as it
>>only makes use of operations that have definitions for all the data
>>types).  For example you can write a procedure to insert something in
>>a tree without knowing the type of the object: (Icon code)
>>...
>>The only operations on x are object comparison (<<<) and inserting
>>into a record, so the procedure is entirely generic.  (As an aside,

>Fine. I can do this in Ada and Eiffel. And assure at compile time, 
>that I don't pass incomparable or uninsertable types to the generic 
>routine.

There's another way.  You can have static type inference, as in ML,
if all you really want is generic routines without having to type
those pesky type declarations.  You get genericity and static typing
with only a little extra work on the part of the programmer, to
disambiguate types where the type-inference mechanism can't.
Whenever the type inference mechanism fails, you have to tell it
what you really meant. 

On the other hand, the ability to have run-time dynamic types is
important.  There are times when you really want a collection of
objects of different types.  But maybe the best compromise is to
use type-inferred static typing by default, and have a way of
specifiying real runtime polymorphism as well.   Most of the gain
without most of the pain.  (No, I don't have a proposal as to what
such a language ought to be like, in detail.  Others probably do, though.)

>>But in my experience this is a minor
>>problem, and the time spent looking for these errors is quite small
>>compared to the time that would have been spent writing strongly typed
>>declarations.

  I don't know about this.  For big and long-running programs, it's nice
to have your really stupid bugs statically detected rather than having
to actually run them, etc.  For medium-sized programs, maybe static type
inference can reduce the typing burden (in two senses :-) on the programmer 
enough to make it worthwhile.  Sometimes I think that having to specify
static vs. runtime polymorphism might be good for the clarity of thought
and expression that it encourages.

    -- PRW
-- 
Paul R. Wilson                         
Software Systems Laboratory               lab ph.: (312) 996-9216
U. of Illin. at C. EECS Dept. (M/C 154)   wilson@bert.eecs.uic.edu
Box 4348   Chicago,IL 60680