Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utcs!mnetor!seismo!nbires!hao!hplabs!tektronix!reed!mdr
From: mdr@reed.UUCP
Newsgroups: net.lang.st80
Subject: Re: Typed Smalltalk
Message-ID: <3885@reed.UUCP>
Date: Sun, 20-Jul-86 19:18:56 EDT
Article-I.D.: reed.3885
Posted: Sun Jul 20 19:18:56 1986
Date-Received: Mon, 21-Jul-86 06:07:23 EDT
References: <799@cit-vax.Caltech.Edu> <9000006@uiucdcsp>
Reply-To: reed!tektronix!BAtkinson.pa@Xerox.arpa (Bob Atkinson)
Organization: Xerox Parc NW, Portland, Oregon
Lines: 69

Summary:

Expires:

Sender:

Followup-To:


In article <9000006@uiucdcsp> johnson@uiucdcsp.CS.UIUC.EDU writes:
>
>When thinking about a type system for Smalltalk, you should forget
>all about Pascal types.  A Smalltalk type system must allow any
>reasonable Smalltalk program to be type-correct, so it must allow
>polymorphism, "abstract" types (where the type is defined by the
>messages that members of that types understand), 

These are often referred to as ``protocols'', as in Stream protocol,
Collection protocol, etc.  

>                                                 inheritance, etc.
>It turns out that inventing an appropriate type system is quite
>difficult, though there have been some successes recently.
>
>There are a number of reasons that a type system would be useful.
>
>1)  Efficiency.  I put this first because it is the primary reason
...
>2) Documentation.  It takes quite a while for a new Smalltalk programmer
...

I quite agree with these two.

>3) Improve robustness of code.  Those using Smalltalk to prototype
>systems or to build systems for their own use will not find this
>argument compelling, but those who want a language that allows them
>to build applications that can be distributed to thousands of users
>will.  A type system can make "message not understood" errors
>impossible, which is important if the reader of those messages
>is likely to be a secretary or, worse yet, a fighter pilot.  The

I find the idea of ST running a fighter plane amusing.  Perhaps
we can get the laws of physics to slow down by an order of magnitude
as well. :-) :-)

I don't think a type system (at least what I imagine when I say
type system, and what most peope who have thought about ST type
systems seem to think) is sufficient to solve this problem. 
How, for instance, can a type system known that in my ST image,
labels on views can slide back and forth under user control?
If your code expects the label to be in the upper left corner,
then ``bad things'' will happen.  The problem in general has to
do with the fact that there is no sense of a kernel in ST-80 as
it exists now.  As an application programmer, you really can not
rely on ANY code in your customers image being the same as in
your image.  (Caveat: this is not true if the Customer has no
programming ability but is merely an end user)  A type system
can only provide a small part of the solution to this problem.

>usual receiver of these messages is nil, so a type system must also

??? Not in my experience.  nil has only marginal preference over other
objects.

>prevent improper accessing of uninitialized data, improper termination
>of iteration of lists, etc.  It would be nice if we could have a
>language that provides all the good features of Smalltalk while 
>letting the machine check that methods are always used as their
>designer intended.  

The hard part, of course, is expressing ``what the designer intended''
in a way that the machine can understand without resorting to writing
the code a second time.  Tall order!!

>Ralph Johnson

	-bob atkinson	
	BAtkinson.pa@Xerox.arpa