Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site watdaisy.UUCP
Path: utzoo!watmath!watnot!watdaisy!lmpopp
From: lmpopp@watdaisy.UUCP (Len Popp)
Newsgroups: net.lang.st80
Subject: Re: Typed Smalltalk
Message-ID: <7815@watdaisy.UUCP>
Date: Tue, 15-Jul-86 13:13:50 EDT
Article-I.D.: watdaisy.7815
Posted: Tue Jul 15 13:13:50 1986
Date-Received: Wed, 16-Jul-86 02:35:59 EDT
References: <799@cit-vax.Caltech.Edu>
Reply-To: lmpopp@watdaisy.UUCP (Len Popp)
Organization: U of Waterloo, Ontario
Lines: 24
Summary: 

In article <799@cit-vax.Caltech.Edu> susser@cit-vax.Caltech.Edu (Joshua B. Susser) writes:
>I have recently noticed few messages related to adding type mechanisms
>to Smalltalk.  I fail to see the appeal in adding types to Smalltalk.
>Is there any advantage to a strongly typed Smalltalk?

I was waiting for someone more knowledgeable than me to respond to this (you
know who you are :-) ), but ...

The raison d'etre for the Smalltalk type systems that I have heard of is not
to provide strong typing for debugging purposes, but to facilitate
native-code compilation!

For example, method lookup is responsible for a lot of overhead in the
Smalltalk bytecode interpreter (at least in some implementations).  If the
classes of objects are known at compile time, then the method lookup can be
replaced by a simple procedure call.  And think about how much time would be
saved if SmallInteger arithmetic could be coded inline, using the CPU's
built-in arithmetic instructions rather than message sends.

Bob Atkinson, at Xerox PARC, has obtained good results from a type inference
system in a native-code compiler.

							   Len Popp
{allegra,decvax,ihnp4,tektronix,ubc-vision}!watmath!watdaisy!lmpopp