info-mac@uw-beaver (info-mac) (09/26/84)
From: Rik Sprague <SPRAGUE@SU-SCORE.ARPA> At the Rochester Forth Conference last June, there was a paper by some people at Kriya Systems (a.k.a. the "Typing Tutor" people) called "Forth meets Smalltalk" describing their object-oriented version of Forth that is up and running on the Mac. I don't think they have plans to market it (although I don't know for sure), but what I saw was impressive. It makes it a LOT easier to talk to Quickdraw when you have some notion of classes and objects. I can give a lot more information about this if more people are interested. Rik Sprague -------
info-mac@uw-beaver (info-mac) (10/28/84)
From: Rik Sprague <SPRAGUE@SU-SCORE.ARPA> A lot of people have asked me about a smalltalk-like object-oriented system in FORTH on the macintosh. This is my summary of a paper called "Forth Meets Smalltalk" by Charles B. Duff and Norman D. Iverson of Kriya Systems, inc. I can't find a copyright notice on the paper, so I'm reprinting much of it verbatim, intermixed with my own comments and ideas. I'm assuming that you already know about object-oriented programming, and/or have read Golberg and Robson's "Smalltalk-80: The Language and Its Implementation" (Addison/Wesley 1983). First, let me say that I am not the world's biggest Smalltalk fan, although it's certainly preferable to the Pascal/ADA way of doing things. I think object-oriented programming is nice, but LISP and PROLOG are still the most elegant way to go in a lot of cases. One of the nicest things about FORTH is that it can produce very compact code, which is awfully important on such a small machine. Unfortunately, that efficiency comes only for a big price in readability and understandability. One of the goals that these people have partly accomplished, I think, is a more understandable FORTH. Conventional Smalltalk and FORTH have one critical feature in common: they're interactive. Programming a Macintosh in anything but an interactive environment is, well, bearskins and stone knives. They have a version of their language up and running today on the Mac, but I'm not sure about any plans they have for marketing it or making it available to the general public. >Because of Forth's extensibility, it is possible to create nearly any >desired data structure with an infinite variety of implementations, >both good and bad. We propose a set of design goals for building >"ideal" data structures in any extensible language, and then describe >how we have implemented a set of extensions to Forth that supports a >much improved data structure definition process. Duff and Iverson describe their guidelines for building "ideal" extensible data structures: 1) realism, it should closely map the problem domain; 2) transparency, names for operations should be insensitive to the actual implementation of the data; 3) localization; 4) independence; 5) encapsulation; 6) aggregation; 7) inheritance; and 8) efficiency. >The object-oriented approach of Smalltalk-80 has benefits in all the >areas except efficiency, which is one of Forth's paramount virtues. >Thus, we undertook to build an object-oriented environment on top of >the Forth nucleus, preserving as much as possible the existing Forth >interpreters and compiler. >The problem with Smalltalk is that it is poorly suited as a production >language due to the runtime overhead of its bytecode interpreter, >method lookup due to late binding and extensive dynamic memory >management. In general Smalltalk is optimized for a highly >interactive environment, rather than a turnkey application under which >time and space are critical. Also, Smalltalk tends to hide the >hardware from the programmer, making it inappropriate for many of the >problems currently being solved by Forth. >When operating under the message/object paradigm, the task of >programming becomes a very different process [from traditional Forth >or procedure-based programming]. Instead of coding sequences of >operations upon data, the programmer creates classes, instances of the >classes (objects), and sequences of message exchanges between the >objects. The design process becomes one of identifying the objects in >a system as aggregates of data and operations, rather than separately >identifying data structures and procedures that use them. An example: >We will show some examples of the syntax in our class/object >extensions. Our primary example is the construction of the class >Outputstring, whose superclass chain leads via classes String and >Bytearray to Object. These are presented as figures 5, 4, 3 and >respectively. Class Outputstring requires an indexed data area which >will hold the string's text; it also contains named instance >variables which hold the output characteristics of the string such as >text display attributes, screen location, and a numeric value which is >displayed following the text string. Methods are provided to set >these values, and to use them to display the string. In particular, >the print method is redefined for Outputstring. For this object, >printing will set the text attributes and screen location prior to >displaying the string and value. > >As a subclass of String, Outputstring inherits String's methods for >managing the text. These methods serve to initialize the text, print >it, and allow insertion, deletion, concatenation, and replacement of >substrings. The named instance variables which describe the text >attributes for Outputstring are appended to those of String, which >hold the string's current length and the current position marker. > >String in turn receives Bytearray's methods. These simply enable >indexed access to the individual characters of the string. Finally, >Object's methods provide facilities for obtaining the address of a >given object, the number and width of its indexed elements, and so >forth. The print method for Object produces a formatted dump of its >own data area. > >Instantiation of @i( Outputstring) is accomplished with the statement: > > 20 Outputstring MYSTRING > >This creates an object MYSTRING with room for 20 characters of text. >The object may now be references with any of the selectors defined in >its methods dictionary. Most of the rest of the paper tells about the implementation of this kind of system in FORTH. Very briefly, they make it work by putting a pointer to the PFA of the class that created a dictionary entry in the CFA of the child. This also gives them the ability to do late-binding for extra performance. This turns out to be very handing in building objects representing operating system control blocks on the Macintosh, which is data- and event- driven, rather than time-driven. To me, this seems like a much better way to do things than C or Pascal. What I'd @i( really) like to see, though, is something that would make the Mac act like a LISP or PROLOG machine. I would love to hear from anyone with additional information on Macintosh LISP or PROLOG, or more Smalltalk stuff. It blows the Lisa development system out of the water. Rik Sprague, Stanford -------