susser@cit-vax.UUCP (07/13/86)
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 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. When I first encountered Smalltalk two years ago, I was overjoyed to find a useful untyped language. In the past two years, I have realized that Smaltalk is indeed typed, but in a more subtle, useful way than compiler writers would have us believe a language should be typed. In my mind, computers are supposed to do the grungy work and let me do the creative work. Declaring types is grungy work that does nothing for me and should be handled by the computer in some way. Smalltalk does just that. If I use the wrong class of object, I quickly find out about it when a 'message not understood' window pops up on my display. It is then ridiculously easy to find what I have done wrong and correct it. I find dealing with types in pascal much less satisfying. I have also found that one of Smalltalk's stongest points is its polymorphic nature. Smalltalk's numeric system and collection classes are two of the best examples of the power and flexibility that an untyped polymorphic language can give you. When I write a numeric algorithm in Smalltalk, it is useful for all kinds of numbers - SmallInteger, LargeInteger, Float, Fraction, Complex, Matrix, or any other kind of number I care to write - and I just don't care what type of number somebody may pass to my method. In those few cases when I do care, I can easily determine an object's species or class and make an intelligent decision based on that information. If there is something that type checking can bring to Smalltalk, I just don't see it. If there is someone out there who does see an advantage to types in Smalltalk, I'd like to hear about it. (Sounds like a good topic for a net discussion to me.) -- Josh Susser susser@csvax.caltech.edu susser.pasa@xerox.com Rectangle allInstancesDo: [ :rect | Display reverse: rect].
gvcormack@watmum.UUCP (07/13/86)
> 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? Does typing have any place in programming languages? Yes it does. Are existing statically typed languages inadequate? Yes they are. Is Smalltalk untyped? No. It is dynamically typed. There is no doubt that dynamic typing and dynamic procedure binding like in Smalltalk offer the programmer a lot of flexibility. However, they also make it very difficult to make assertions about what the program does. I do not agree at all that "one quickly gets an obvious error message" when one runs an incorrect Smalltalk program; it may run for years before crashing, and when it does, the bug may be anything but obvious. So I am 100% behind any attempt to introduce static type checking (which would guarantee that the error "don't understand xxx" would never occur), provided that it does not destroy the polymorphic capabilities of the language. Everyone interested in this topic should read "Implementing Russel" by Boehm and Donahue in Proc. Sigplan 86 (June Sigplan Not.). -- Gordon V. Cormack CS Department, University of Waterloo uucp: { allegra, decvax, ... }!watmath!gvcormack csnet: gvcormack%watmum@waterloo cdn: gvcormack@mum.waterloo.cdn
siritzky@acf2.UUCP (07/14/86)
Just a few comments: 1. If you have ever written a compiler you would know that adding strong typing does not make the compiler writers job any easier. Quite the opposite is true. The typing of Ada has added quite some complexity to the compilers. 2. Smalltalk was probably intended to be strongly typed. This I get from the early papers on the language. It looks like the reasons that it is not is that it was too difficult to implement. 3. Why have strongly typed languages? I think that you will find that anyone who has written a large program will agree that strong typing is a very useful aid in developing these systems.
johnson@uiucdcsp.CS.UIUC.EDU (07/14/86)
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
susser@cit-vax.UUCP (07/15/86)
Gordon Cormack <gvcormack@watmum.uucp> writes: > There is no doubt that dynamic typing and dynamic procedure binding > like in Smalltalk offer the programmer a lot of flexibility. However, > they also make it very difficult to make assertions about what the > program does. I do not agree at all that "one quickly gets an > obvious error message" when one runs an incorrect Smalltalk program; > it may run for years before crashing, and when it does, the bug may > be anything but obvious. I will agree that incorrect Smalltalk programs do not always produce obvious error messages. The point I was trying to make was this: if there were a type error in my program the 'does not understand' message I would get at run-time would notify me of the error just as well as a compile-time error report. By the way, it's true that incorrect Smalltalk code can run for years without crashing - just try using processes. But I remember seeing a book called 'The C Puzzle' or something like that that was a listing of a very long, boring looking program that supposedly did something very obvious. Also included was the output of the program, which was completely mistifying and entirely different from what you would expect. The puzzle was to find the error, a ONE CHARACTER mistake! I know this is anecdotal evidence, but it seems to me like Smalltalk has nothing on C for producing bugs that are anything but obvious. > So I am 100% behind any attempt to introduce static type checking > (which would guarantee that the error "don't understand xxx" would > never occur), provided that it does not destroy the polymorphic > capabilities of the language. I think static type checking would necessarily destroy the polymorphic nature of Smalltalk. Types would have to be declared and message bindings checked at compile time. Even allowing that variables could be one of several specified types, how would you deal with performs, or with applications that created new classes on the fly? What if you overrode an inherited message in a subclass - what would happen to the already set binding to the superclass's method? What if I wanted to make a subclass of ByteArray that masqueraded as a Float but had infinite precision (similar to LargeIntegers) - would this be a type clash, or would I have to cast the LargeFloat as a regular Float? Even in a well-implemented system, static typing would be much more work for the programmer. And, I maintain, all this extra work would be of no benefit, and probably some detriment. There is not a problem with the way typing is handled in Smalltalk currently. The vast majority of bugs in Smalltalk programs are not type errors. A type-checking compiler would not be a useful tool in Smalltalk - there are already plenty of tools in Smalltalk to allow me to make certain I know what I'm doing. Static typing is for early-bound, non-polymorphic languages. 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. :-) --Josh Susser susser.pasa@xerox.com (preferred email box) susser@csvax.caltech.edu Smug was I ere I saw gums.
lmpopp@watdaisy.UUCP (Len Popp) (07/15/86)
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
emjej@uokvax.UUCP.UUCP (07/15/86)
Josh Susser says... >I have also found that one of Smalltalk's stongest points is its >polymorphic nature. Smalltalk's numeric system and collection classes >are two of the best examples of the power and flexibility that an >untyped polymorphic language can give you. When I write a numeric >algorithm in Smalltalk, it is useful for all kinds of numbers - >SmallInteger, LargeInteger, Float, Fraction, Complex, Matrix, or any >other kind of number I care to write - and I just don't care what type >of number somebody may pass to my method. Agreed, wholeheartedly! This is, however, a property independent of OOPS (and I will say nothing further, for fear of restarting pointless flamage). For example, the programming language Russell is strongly typed, but lets one write, for example, a single quicksort procedure that not only sorts things of any type for which there is a comparison operator, but also doesn't care how arrays are implemented underneath. (Maybe not of much use for quicksort, but it's nice to have, say, Gaussian elimination routines that don't have to be rewritten for band, sparse, polka-dotted, etc. matrices.) James Jones
johnson@uiucdcsp.UUCP (07/16/86)
Josh Susser <susser@cit-vax.Caltech.Edu> writes: > I know this is anecdotal evidence, but it seems to me like Smalltalk has > nothing on C for producing bugs that are anything but obvious. C has a poor excuse for a strong type system. Actually, it doesn't even pretend to be a strong type system. > I think static type checking would necessarily destroy the polymorphic > nature of Smalltalk. Types would have to be declared and message > bindings checked at compile time. Even allowing that variables could > be one of several specified types, how would you deal with performs, > or with applications that created new classes on the fly? One way to implement perform is to make a string representing the message and evaluate it. Evaluation calls the compiler, which type-checks the expression, so type-safety is maintained. This would probably be quite slow, which would be ok by me, since I think that performs are ugly and unnecessary. (I think that I'm probably in the minority on this point.) Creating new classes by applications is no harder than creating new classes by the browser. Of course, this does not necessarily mean that either is easy. > What if you > overrode an inherited message in a subclass - what would happen to the > already set binding to the superclass's method? Are you overriding the TYPE of the method or just its code? Overriding the code is no problem at all as long as the types are compatible. Some type systems require that types of redefined methods be compatible with the method being redefined, some do not. Adding a type system does not necessarily change the implementation of the language at all. Even if the compiler performs some optimizations, it will still have to implement some Smalltalk programs pretty much the same as it does now, using method look-up. > What if I wanted to > make a subclass of ByteArray that masqueraded as a Float but had > infinite precision (similar to LargeIntegers) - would this be a type > clash, or would I have to cast the LargeFloat as a regular Float? The subclass of ByteArray is not a Float. However, it acts like a Float. You should not usually write code that requires objects to be in a particular class. Instead, you should require that objects have certain behavior. > Even in a well-implemented system, static typing would be much more > work for the programmer. And, I maintain, all this extra work would be > of no benefit, and probably some detriment. A real type system for Smalltalk (as opposed to a toy type system for only a part of the language) has to address all these questions. Ideally, static type checking should be virtually invisible to the programmer. This is why many of the early papers tried to invent type inference systems. I don't think that useful types can be inferred from Smalltalk programs (I would be glad to be proved wrong) but it should still be possible to remove almost all the burden from the programmer. At the moment, I think that it should only be necessary to have the programmer explicitly type instance variables and to infer the types of methods and other variables. > 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.
jans@tekecs.UUCP (Jan Steinman) (07/16/86)
In article <546@watmum.UUCP> gvcormack@watmum.UUCP (Gordon V. Cormack) 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. > >So I am 100% behind any attempt to introduce static type checking >(which would guarantee that the error "don't understand xxx" would >never occur), provided that it does not destroy the polymorphic >capabilities of the language. Please! Don't take away my "does not understand" notifier! This is vastly different than your typical C complie time message: "line 24: type mismatch". Chances are you've arrived at this notifier as a result of either "perform:"ing into a dictionary or by not using the browser. Static type checking would do little for the former, and Smalltalk programming experience quickly cures the latter. (Compare with a new C programmer who doesn't use sections 2 and 3 of the manual.) I've recently become convinced there is *one* use for type checking in Smalltalk: when Smalltalk is being interfaced with type checked languages! -- :::::: Artificial Intelligence Machines --- Smalltalk Project :::::: :::::: Jan Steinman Box 1000, MS 60-405 (w)503/685-2956 :::::: :::::: tektronix!tekecs!jans Wilsonville, OR 97070 (h)503/657-7703 ::::::
graham@qmc-cs.UUCP (07/19/86)
I have implemented and used a simple type checking system for Smalltalk. This has convinced me that a type checking Smalltalk compiler for the standard Smalltalk system is both possible and very useful. My motivation has been the desire to improve the language, the programming environment and a firm belief in strong type checking. I currently have a type checking system based along the ideas presented in the paper by Borning & Ignalls about type checking Smalltalk. Basically, type declarations are added to messages and variables and then used by the compiler. Type declarations specify what sort of object is expected, using the idea of 'classes as types'. Each class has a corresponding type, with the types existing in a type-subtype hierarchy. This system actually has a number of serious shortcomings but has served its purpose in finding out what they are and investigating potential solutions. The next incarnation should be genuinely useful. What are the main benefits of strong type checking? - Elimination of DoesNotUnderstand errors at runtime. No more messing about with the debugger trying to track down type errors. - Early detection of errors. The programmer can be told of and deal with errors at compile time. The compiler should detect as many errors as possible, rather than simply turn out code regardless. - Documentation. I must have spent hours searching through the system trying to find what sorts of objects may be passed as parameters with a message, or what a variable is used for. The Smalltalk system is very big and it needs this extra layer of specification. - Separation of the specification of what is done from how it is done. A class defines a set of messages (just names) and method bodies. Very often the method body is the only specification of what a message does. If you're lucky it will contain some useful comments, usually you're stuck with trying to understand code. A type system can be used to specify the protocol of an object without having to delve into implementation details. - System managment. A type system can be used to check that all the components of the system fit together and that new components fit with the existing ones. This is very important, think of the amount of information within the Smalltalk environment. There must be reliable tools to manage it. To conclude, I believe that a strong type checking system for Smalltalk is possible, for the system as it stands now. It can be interactive, unobtrusive, useful and a genuine enhancement to the system. Graham Roberts Queen Mary College, University of London graham@uk.ac.qmc.cs
mdr@reed.UUCP (07/20/86)
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
mdr@reed.UUCP (07/21/86)
Summary: Expires: Sender: Followup-To: In article <803@cit-vax.Caltech.Edu> susser@cit-vax.Caltech.Edu (Joshua B. Susser) writes: > >I think static type checking would necessarily destroy the polymorphic >nature of Smalltalk. Types would have to be declared and message >bindings checked at compile time. Even allowing that variables could This is not i(necessarily) true. If one allows types to specify unions of classes rather than just singletons, the polymorphic nature of the language can be maintained. Further, if one treats the type declarations merely as HINTS, and not absolutes, allowing the programmer to violate them at his will if he so desires, then we eliminate the problem with a perform. An interesting point for ST-80 compiler writers is that actually doing a real message send can change the state of the image ARBITRARILY. Treating type declarations and inferrences based on them merely as hints and providing graceful fallback code helps to get around this problem. >be one of several specified types, how would you deal with performs, >or with applications that created new classes on the fly? What if you Have you done this (dynamic classes, that is)? I have just recently, and I had to pull some rather sneaky tricks to get things to work how I wanted. If this was anything more than a passing remark, I'd like to hear more. >Even in a well-implemented system, static typing would be much more >work for the programmer. Here here! > And, I maintain, all this extra work would be >of no benefit, and probably some detriment. > >There is not a problem with the way typing is handled in Smalltalk >currently. The vast majority of bugs in Smalltalk programs are not >type errors. I would most certainly concur on that. > A type-checking compiler would not be a useful tool in >Smalltalk - there are already plenty of tools in Smalltalk to allow me >to make certain I know what I'm doing. Static typing is for >early-bound, non-polymorphic languages. There are two reasons I can think of for a type system: helping to generate more efficient code, and to educate novice users. I don't want to repeat myself too much, so see other posting today. >--Josh Susser > susser.pasa@xerox.com (preferred email box) > susser@csvax.caltech.edu -bob atkinson BAtkinson.pa@Xerox.(arpa||com) BAtkinson.pa%Xerox.com@Csnet-relay.csnet
mdr@reed.UUCP (07/21/86)
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
mdr@reed.UUCP (07/21/86)
Summary: Expires: Sender: Followup-To: In article <9000007@uiucdcsp> johnson@uiucdcsp.CS.UIUC.EDU writes: >Even if the compiler performs some optimizations, it will still have >to implement some Smalltalk programs pretty much the same as it does >now, using method look-up. ... at least if the code wasn't doing what the compiler thought it would do when it compiled the code. One the biggest wins of a ST type system will be the ability to eliminate many of the dynamic method lookups that occur, at least if the programmer has hinted the compiler in the right direction. >> What if I wanted to >> make a subclass of ByteArray that masqueraded as a Float but had >> infinite precision (similar to LargeIntegers) - would this be a type >> clash, or would I have to cast the LargeFloat as a regular Float? > >The subclass of ByteArray is not a Float. However, it acts like a Float. >You should not usually write code that requires objects to be in a >particular class. Instead, you should require that objects have certain >behavior. That's of course true, and it points to one of the hardest problems in adding a type system/optimizing compiler to ST. To do any reasonable amount of optimization, one needs to get rid of many dynamic method lookups, and to do this necessitates finding the actual code executed by other message sends. This requires knowing the classes of message receivers, since this is what descriminates the method executed at run-time. This is why every ST type system that I have heard of has been class/set of classes oriented. This is in conflict with the progamming practice of ``progamming by protocol'', that is, not caring about classes per se, but only on the messages responded to. -bob atkinson BAtkinson.pa@Xerox.com
johnson@uiucdcsp.CS.UIUC.EDU (07/30/86)
/* Written 3:56 pm Jul 20, 1986 by <bob atkinson> BAtkinson@Xerox.com */ >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. It seems to me that a compiler that treated type declarations as hints would not be able to make nearly as many optimizations as one that performed static type checking. For example, a compiler should be able to detect that most block contexts will never be assigned to any instance variable and so the method contexts that created them can be allocated on a stack. However, the method context is allocated long before the block context is sent to an object, and whether or not the block context is assigned to an instance variable depends on the class of the receiver. I suppose that the method could transfer its context to the heap at run-time, depending on the class of the receiver, as in the Deutsch-Schiffman implementation, but that does not seem optimal. I would like to perform the same trick with any object whose lifetime can be determined. Type declarations as hints should work well for method arguments, since the class of these variables cannot change during execution of the method (except by a becomes:). Thus, it should be possible to test their class only at the beginning of a method. However, an instance variable or a local variable that is changed inside a loop will have to be repeatedly tested. It seems to me that a lot of possible speedup would be lost. I would be glad to hear otherwise. >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. I've been teaching a lot of people Smalltalk, and it is clear to all of us that a type system would make the system (not necessarily the language) easier to learn. In our image, at least, some of the comments are wrong. However, the usual problem is that there are just not enough of them. Types would provide additional information that should make the system easier to learn. Ralph Johnson johnson@cs.uiuc.edu or ihnp4!uiucdcs!johnson
johnson@uiucdcsp.CS.UIUC.EDU (07/30/86)
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