Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cbatt!cbosgd!ihnp4!inuxc!pur-ee!uiucdcs!uiucdcsp!johnson
From: johnson@uiucdcsp.CS.UIUC.EDU
Newsgroups: net.lang.st80
Subject: Re: Typed Smalltalk
Message-ID: <9000010@uiucdcsp>
Date: Wed, 30-Jul-86 12:48:00 EDT
Article-I.D.: uiucdcsp.9000010
Posted: Wed Jul 30 12:48:00 1986
Date-Received: Sat, 2-Aug-86 01:31:42 EDT
References: <799@cit-vax.Caltech.Edu>
Lines: 57
Nf-ID: #R:cit-vax.Caltech.Edu:799:uiucdcsp:9000010:000:2906
Nf-From: uiucdcsp.CS.UIUC.EDU!johnson    Jul 30 11:48:00 1986


I would like to say a few more things about what a proper type system
for Smalltalk must allow.  There are several different kinds of types
that Smalltalk programmers think about:

1) A protocol.  This is called an "abstract type" by the Emerald
people at U. Washington, a "minimal specification" by Jim Purtilo
(soon to be at Maryland) and is essentially the same as signatures
in abstract datatype theory.  It is the way that the blue book
encourages us to program and is actually the essence of Smalltalk
types, but it is not always the way programmers think nor is it
useful for code optimization.

2) A class.  Programmers seem to think this way all too often.
Maybe my problem is that I am not around any Smalltalk wizards,
but it seems to hard to think about abstract protocols instead of
concrete classes.  In addition, class information is necessary for
optimization.

3) A class hierarchy.  A variable called "aCollection" is certainly
not of class Collection, but rather of one of its subclasses.  This
seems to be a very natural definition of a Smalltalk type, but it
has a number of problem.  For example, Collection has some methods
that assume that all its subclasses have an "add:" method, but
Array does not.  Also, Dictionary is used like an Array by sending
"at:" and "at:put:" messages to it.  Perhaps this really indicates
that the Collection hierarchy should be reorganized, but it seems
to me that it means that class hierarchies are not really Smalltalk
types.

4) A set of classes.  A view's controller is either a subclass of
Controller or nil, but nil is not related to controller in any
interesting way.  It seems natural to represent the type of a
view's controller by a set of classes.

A set of classes can obviously represent a class hierarchy.  It turns
out that a protocol is also a set of classes---the set of all classes,
past, present, and future, that implement the protocol.  Of course,
this set is infinite, but all we ever have to do with it is check
whether another type is included within it, which can be easily done
without enumerating it.

Not all classes correspond to types.  Array is not a type, but rather
is a type generator, since we also need to know the type of its elements.
Thus, Array of: Integer is a type, but Array is not.  I describe these
kinds of types as sets of parameterized classes.

If the type of a variable is a small set of classes then it should be
easy to optimize references to it.  If it is in a large set of classes
(as would be produced by defining a type by protocol) then it will be
hard to optimize code accessing it.  I suppose that you can fall back
to using hints as described by Bob Atkinson.  However, I think that
any type system, especially one that will have static type checking,
should allow as many of the currently used mental type systems as
possible.

Ralph Johnson   johnson@.cs.uiuc.edu  ihnp4!uiucdcs!johnson