Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!uunet!bywater!scifi!watson!arnor!andreadoria!strom
From: strom@watson.ibm.com (Rob Strom)
Newsgroups: comp.lang.misc
Subject: Re: Run-time Type Errors in Smalltalk (LONG)
Message-ID: <1991May23.144842.21481@watson.ibm.com>
Date: 23 May 91 14:48:42 GMT
References: <1991May17.011209.29486@tkou02.enet.dec.com> <1991May17.051840.26916@daffy.cs.wisc.edu> <1991May21.155753.8615@watson.ibm.com> <1991May22.161814.15196@daffy.cs.wisc.edu>
Sender: news@watson.ibm.com (NNTP News Poster)
Reply-To: strom@andreadoria.watson.ibm.com (Rob Strom)
Organization: IBM T.J. Watson Research Center
Lines: 27
Nntp-Posting-Host: andreadoria

In article <1991May22.161814.15196@daffy.cs.wisc.edu>, quale@saavik.cs.wisc.edu (Douglas E. Quale) writes:
 
|> Static + dynamic typing in the same language might overcome any problem.
|> Suppose however, that only static typing is supported.  How does Ada or SML
|> handle the resource problem in the X Toolkit?  It must be possible for a
|> widget writer to add arbitrary types to his widgets, and not have to
|> recompile libXt.a, the X Toolkit library.  The C implementation simply uses
|> unchecked dynamic typing.  This is much worse than using a language that
|> supports dynamic typing because no type checks are performed even at run
|> time.  Is there a better way?
|>
Hermes uses "polymorphs".  You apply the "wrap" operator to a value of any
data type.  The result is a value of type "polymorph", which can be stored
in a variable of type "polymorph".  It can be copied, stored, and passed
around, but no type-specific operations can be applied.  You must then
"unwrap" the polymorph into a variable of type T before applying operations
appropriate to type T.  A runtime check is made that the wrapped polymorph
value actually is of type T.

This allows dynamic typing where needed, while retaining static typing as
the more common situation.  Whether checked statically or dynamically,
type safety (plus "typestate safety" --- e.g., avoiding reading undefined data)
is always assured.
 
-- 
Rob Strom, strom@watson.ibm.com, (914) 784-7641
IBM Research, 30 Saw Mill River Road, P.O. Box 704, Yorktown Heights, NY  10598