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: <3883@reed.UUCP> Date: Sun, 20-Jul-86 16:56:36 EDT Article-I.D.: reed.3883 Posted: Sun Jul 20 16:56:36 1986 Date-Received: Mon, 21-Jul-86 06:06:53 EDT References: <799@cit-vax.Caltech.Edu> <9000007@uiucdcsp> Reply-To: reed!textronix!BAtkinson.pa@Xerox.arpa (Bob Atkinson) Organization: Reed College, Portland, Oregon Lines: 63 In article <9000007@uiucdcsp> johnson@uiucdcsp.CS.UIUC.EDU writes: >> Smalltalk does not need strong typing. Try writing a large system in >> Smalltalk. Go ahead, I dare you. You will find that you have >> absolutely no need whatsoever for strong type checking. If my >> arguments will not convince you, then experience is the only thing >> that can. If experience will not convince you, then you deserve to >> program in a strongly typed language. :-) > >Note the authors of the following paper. > >A.H. Borning and D.H.H. Ingalls. >A type declaration and inference system for Smalltalk. >In Conference Record of the Ninth Annual ACM Symposium on > Principles of Programming Languages, pages 133--139, 1982. So? Admittedly these are well-known people, but do you really have any idea what the goals of that particular project were?. It wasn't necessarily to remedy any crucial programming envrionment deficiency. More likely, it was to experiment and see what the realm of possibility of a retro-fitted type system were. After all, PARC is a research lab. Let's quit the name-dropping. Having done a LOT of Smalltalk-80 programming in the last two year, and having spent most of last year working on my own type system and optimizing compiler, I am very inclined to agree with the >> quotation. As a programmer, I feel no NEED for a type system in Smalltalk. The rich set of tools provided by the programming environment eliminate the need for much of the hand-holding provided by a strong type system. I VERY rarely get doesNotUnderstand: messages, and it is not clear to me that one can come up with a type system to get rid of the remaining few, or if it is worth the effort to do so. The only real uses for a type system that I can see are to a) Expand the realm of compiler optimizations possible in order to increase system speed. The key thing that a type system adds is the ability to statically bind some of the method lookups. Once this is done, then methods tend to look a lot more like classical language procedures, and become much more amenable to classical optimization techniques (code motion out of loops, tail recursion elimination, loop unrolling, array index factoring, etc...) Note that this is NOT in conflict at all with the current language or the current flexible progamming style. One can treat type declarations soley as HINTS and allow the programmer to violate them at will but perhaps suffer the cost of decreased speed. b) Improve documentation for novice users. A crude, ad-hoc, and etherially (sp?) defined type system is already found in many of the class commments. The default comment (at least in my ST image :-)) provides templates for each of the instance variables and a place to describe the ``type'' of the variable. A real type system could formalize this and be able to actually make use of the information. We have the added bonus that programmers unfamiliar with the class can get an idea of what the class feels like by looking at its type declarations. This, coupled with the easy ability to browse any reference to an instance or class variable gives a very quick way to get an idea of the purpose of any particular variable. -bob atkinson BAtkinson@Xerox.com BAtkinson%Xerox.com@CSnet-relay.csnet or any other incantation that gets you to the arpa net