Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!samsung!uunet!bywater!arnor!andreadoria!strom
From: strom@arnor.UUCP (Rob Strom)
Newsgroups: comp.lang.misc
Subject: Re: Static type inference? (was Re: Runtime Polymorphism)
Message-ID: <1991Mar6.163544.15007@arnor.uucp>
Date: 6 Mar 91 16:35:44 GMT
References: <559@coatimundi.cs.arizona.edu> <2741@enea.se> <1991Mar5.180306.1561@uicbert.eecs.uic.edu>
Sender: news@arnor.uucp (NNTP News Poster)
Reply-To: strom@andreadoria.watson.ibm.com (Rob Strom)
Organization: IBM T.J. Watson Research Center
Lines: 79

In article <1991Mar5.180306.1561@uicbert.eecs.uic.edu>, wilson@uicbert.eecs.uic.edu (Paul Wilson) writes:
|> sommar@enea.se (Erland Sommarskog) writes:
|> 
   [embedded quote from David Gudeman deleted]

|> >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.)

That is the approach we took in Hermes.  Most of the time, the programmer
intends that a variable always contain values of
the same specific type.   Occasionally, it is desirable to
have a collection of objects of different types.  Hermes
provides type constructors and a mechanism for explicit type 
definition to handle the typical case in which
the type is statically invariant.  It provides an additional type, "polymorph", 
for the cases when data of different types are to be handled by a common
piece of code.  Data of any type can be "wrapped" into a polymorph,
and then cast back into a variable of the original type by being
"unwrapped".  (Of course, at this time it is checked that the polymorph
in fact has the expected type.)  

 
|> 
|> >>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.

In Hermes we take an intermediate position on declarations.  There is
a type inferencing mechanism.  The same rules used to perform type
checking can be used in certain cases to perform type inferencing when
the type is not known.  However, Hermes is biased towards the needs
of the writer of long-running programs.  It therefore requires more declarations
than would be necessary to satisfy the type inferencing mechanism.  In particular,
interfaces are required to be explicitly typed.  

The use of the "polymorph" type is independent of our position on declarations.
It's just another type which can be declared or inferred.  We do insist
that "wrap" and "unwrap" be explicitly coded, since our position is that
run-time type checking is the exception, not the rule.   In an environment
where almost everything is a polymorph and only a few things explicitly
typed, we might have made a different decision.

|> 
|>     -- 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 

-- 
Rob Strom, strom@ibm.com, (914) 784-7641
IBM Research, 30 Saw Mill River Road, P.O. Box 704, Yorktown Heights, NY  10958