kjx@comp.vuw.ac.nz (R James Noble) (11/30/89)
In the process of attempting to write a Smalltalk virtual machine and compiler I have come across some quirks of Smalltalk and I would like to know what an implementation _should_ do. I am also interested in the opinion of some experienced Smalltalkers as to any changes or additions to Smalltalk that they might consider useful. I have access to both the Apple Lisa Smalltalk port, an Tim Budd's Little Smalltalk, items (a..c) below refer to these implementations. a) cascade message sends .. foo bar baz ; barf Is the message barf send to (foo bar), as per Blue book and Lisa, or (foo bar baz), like little Smalltalk ? b) blocks The [Miranda] article describes the standard problems with Smalltalk blocks. Is it worth the effort to make blocks fully reentrant and use standard static linkages? Are block temporaries a good idea? (Lisa implementation doesn't, Little Smalltalk copes with some tail recursion) c) modifying literals. The method tmp below. tmp | a | a _ #( 1 1 1 ). a at: 2 put: ( a at: 2 ) + 1. ^a. Three invocations will return (1 2 1) (1 3 1) (1 4 1). Would an implementation that returned (1 2 1) for all invocations be a bug or a feature. (Both Little Smalltalk and Lisa Smalltalk modify the literal each time). d) multiple inheritance. [Borning] describes a multiple inheritance scheme which is (I understand) now standard in ParcPlace Smalltalk. Is this now considered a standard part of Smalltalk? Could another implementation of multiple inheritance be substituted. e) class library How much does a Smalltalk class library need to conform to the Blue Book in order for the system to be usable as a Smalltalk? Which of the following categories could be redesigned without losing the feel of Smalltalk? Numbers and Magnitudes. Collections. Files and Streams. BitBlit graphics. Window System - MVC (Smalltalk/V has altered this). User Interface - browsers, inspectors. Kernel - classes and metaclass hierarchies. (Little Smalltalk modifies this) Kernel - contexts and processes. (Little Smalltalk modifies this) System Compiler & Support. (Little Smalltalk modifies this) f) other strange "features" - instance variable access only by message send (as per [Ungar]), with syntactic sugar to allow Smalltalk methods to compile. - support for one-of-a-kind objects. - altered metaclass hierarchy (a class would be a one-of-a-kind object) - multiple global namespaces (a.k.a. packages) - object destructors - when an object is garbage collected it can cause a message to be sent, for example to deallocate an external object (such as an X window). - anything else you can think of. Please reply by mail; I will summarise if necessary. -- [Miranda] BrouHaHa - A Portable Smalltalk Interpreter, OOPSLA87, p354 [Borning] Multiple Inheritance in Smalltalk-80, AAAI28 [Ungar] Self: The Power of Simplicity, OOPSLA87, p227 -- R James Noble Computer Science Department Victoria University, Box 600, Wellington 1, New Zealand kjx@comp.vuw.ac.nz ...!uunet!vuwcomp!kjx
johnson@p.cs.uiuc.edu (12/03/89)
James Noble's questions about Smalltalk implementation are much too interesting to make private, and there is not that much traffic in comp.lang.smalltalk. The little Smalltalk definition of cascades are definitely nonstandard and, in my opinion, wrong. They can be replaced easily by parenthesis. Blocks are becoming more and more like Scheme closures. It isn't hard to make blocks fully reentrant and use standard static linkages. I think that block temporaries are a good idea. They are especially useful for parallel programming (though that probably isn't important for many people). Literals are a tough problem. The only literals that real pose a problem are array literals, because you can't change numbers or symbols and rarely change strings. In my opinion, Smalltalk would be greatly improved if it were imposible to modify literals. One way to do this is to make a class LiteralArray that does not have the at:put: method. This would be a compromise between the current situation and copying literals every time they appear in a program. If I were you I would certainly put in multiple inheritance. However, I would not use the one described in [Borning]. Nobody really knows the best way to do multiple inheritance, so if you are creative you might invent something useful. It is used so rarely that you would not introduce much incompatibility problems by doing it differently. The class library is another matter. If you want to use other people's programs then you will have to make your class library very close to the standard. Unfortunately, there is no real standard. If all you want is something with the same look and feel as Smalltalk then there is no reason why you have to be compatible at the class level. Any of the classes could be redesigned if you are only interested in the spirit of the language, none of them should be altered if you want your systems to run other people's programs without a lot of hastle. However, it will be virtually impossible for you to be compatible unless you just reuse the class libraries, so perhaps it is not even worth trying. I think it would be very neat to add support for one-of-a-kind objects and use this to try to make metaclasses easier to understand. However, if you aren't careful then your language will look just like Self. Not that this is bad, it just won't be new. Multiple global namespaces (a.k.a. packages) will be seen to be very important in the future. It is easy to implement this feature in Smalltalk-80. I had a student stick classes in pools as a several week class project, and it worked out very well. The pools then act as the packages. It probably wouldn't be hard to do something nicer. Ralph Johnson -- University of Illinois at Urbana-Champaign