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: <9000006@uiucdcsp>
Date: Mon, 14-Jul-86 11:33:00 EDT
Article-I.D.: uiucdcsp.9000006
Posted: Mon Jul 14 11:33:00 1986
Date-Received: Wed, 16-Jul-86 04:16:52 EDT
References: <799@cit-vax.Caltech.Edu>
Lines: 83
Nf-ID: #R:cit-vax.Caltech.Edu:799:uiucdcsp:9000006:000:4766
Nf-From: uiucdcsp.CS.UIUC.EDU!johnson    Jul 14 10:33:00 1986


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), 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
that I got interested in type systems.  A lot of work has been put
into making Smalltalk more efficient.  For example, the work by Deutsch
and Schiffman is truly amazing.  However, there is still a large
efficiency gap between Smalltalk and C.  Implementors of Smalltalk
try to optimize interpreters instead of writing optimizing compilers.
They do this because, without a type system, it is nearly impossible
to optimize Smalltalk programs.  An optimizing compiler for a typed
language should produce code that is about as fast as C code for
comparable cases.

2) Documentation.  It takes quite a while for a new Smalltalk programmer
to learn how to read the system classes.  This is largely because
it is hard to know what any particular method does since it depends
on lots of other methods.  A type system can tell the reader the 
assumptions that are being made about the arguments to a method and
about the instance variables.  Of course, comments can also explain
these assumptions.  However, comments can be wrong (some of the comments
in Smalltalk-80 code are wrong) and are usually incomplete.  A type
system formalizes what the programmer already knows about the design
of the program and allows another way to encode design decisions.

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
usual receiver of these messages is nil, so a type system must also
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.  (Note that Smalltalk lets any programmer redesign
code that is too restrictive; just make a subclass.)

Note that none of these three reasons (except perhaps the first)
are important to those building prototypes and doing personal
programming.  It is my understanding that most Smalltalk programming
is for these purposes.  (I have heard about a few exceptions.)
However, the comments by the Hewlett-Packard implementors on pages
109 and 110 of the green book sum up the attitudes of many people;
Smalltalk is too slow, too dangerous, and not suited for average
programmers.  I think that these attitudes are wrong, but they
are caused by real needs that can, in my opinion, be addressed by
proper type systems.

>I have always felt, deep in my heart, that strongly typed languages
>were invented by compiler writers to make their job easier and my job
>harder.
This raises an important point; a type system should be used to explain
what a program is doing, it should not determine how the program should
be written.  Unfortunately, almost all type systems are too restrictive,
and are used as much to limit programs to those that are easily compiled
as to let the programmer describe the program.  It is probably a mistake
to design the type system first.  A typeless language lets users learn
how to use the language; a type system can then be created to describe
that use.  Of course, inventing a type system later means that there
might be problems integrating it with the rest of the language.  That is
what is happening with Smalltalk.

Smalltalk has many nice features and fills an important niche.  In a
sense, point 1) about efficiency is a red herring, since it doesn't
matter at all how fast "typed Smalltalk" is if the addition of types
ruins the usefulness of Smalltalk for rapid prototyping and developing
new abstractions.  Naturally, I believe that it is possible to make a
typed version of Smalltalk that is as easy to use and as fun to program
as Smalltalk-80.  However, it is up to implementors of new systems to
show that their creations are actually improvements on the old systems.

Ralph Johnson