Object Activities
Volume Number: 4
Issue Number: 7
Column Tag: Forth Forum
Objective Activities in Forth 
By örg Langowski, MacTutor Editorial Board
Objects in Forth, International Resources & A Priority TaskScheduler
One of Forth’s great advantages is its extensibility. Since the Forth compiler is
just made up from other Forth words, and the data structures into which each new
word is compiled are very well documented and accessible to the user, you can very
easily rewrite the compiler and thereby define your own language. (These comments
are obvious to the seasoned Forth user; I’ve just repeated them to emphasize the
difference to the more ‘canonical’ languages like Pascal or C).
With a language as flexible as Forth (very much like LISP in that aspect), it is
no surprise that many have set out to create their own language on top of a Forth
kernel. Famous examples are the object-oriented extensions ForthTalk and, of course,
NEON. While ForthTalk (which has been covered by Paul Snively in MacTutor V3#2)
seems to be alive and well, and still offered by Creative Solutions in their newsletter,
NEON seems to have been all but abandoned by their creator, Kriya Systems. After the
2.0 update, more than a year ago, no more NEON news. And it was such an elegant
implementation of object-oriented programming! Judged from bulletin board posts and
letters I receive every now and then, many of you must be more than disappointed at
the slow disappearance of NEON from the scene of Macintosh languages.
It is about a recent attempt to extend and -maybe- resurrect NEON, and about
several other projects of object-oriented extensions to Mach2 Forth, that I wish to
report this month. A lot of the information I am presenting comes from discussions and
postings on the Mach2 roundtable on GEnie; therefore this column is, again, somewhat
biased towards Mach2. MacForth users, please, read on and comment; a standard for an
object oriented Forth would be appreciated by most of us.
Object Orientation in Forth
Why would one choose Forth to implement an object-oriented language? Besides
the built-in extensibility of the Forth compiler, some aspects of object orientation are
already contained in Forth. As a reminder, an object is a structure that contains not
only data, but also procedures: methods, which can operate on the contents of the object
or on other data. Example: an array of integer numbers which, given an index n,
automatically returns the address of the nth element. The classical Forth definition of a
‘defining word’ for arrays with 32 bit-size elements is:
: ARRAY CREATE ( # - ) 4 * ALLOT
( reserves # cells in the dictionary )
DOES> ( n - adr ) SWAP 4 * + ;
The definition of an array of 100 long integer numbers would then be 100 ARRAY
myArray, while 47 myArray puts the address of the 47th element of myArray on the
stack. When the array is first defined, the CREATE part of the definition is executed,
and space is reserved in the dictionary for the array’s contents. In object-oriented
lingo, this would be called creation of an ‘instance’ myArray of the ‘class’ ARRAY.
myArray’s ‘instance variables’ would correspond to the space reserved in the
dictionary for the 100 32-bit numbers, and its one and only ‘method’ would be the
DOES> part of the definition, which is invoked when the word myArray is executed.
If you now extend the definition ARRAY like this:
: ARRAY CREATE 4 * ALLOT
DOES> swap ( n msg - adr )
CASE
1 OF ( addr: ) SWAP 4 * + ENDOF
2 OF ( at: ) SWAP 4 * + @ ENDOF
3 OF ( to: ) SWAP 4 * + ! ENDOF
;
and define
: addr: 1 ;
: at: 2 ;
: to: 3 ;
47 addr: myArray would return the address of the 47th element, 47 at: myArray
would return its value, and 3 47 to: myArray would store 3 in that cell.
myArray can therefore be viewed as an ‘object’ to which you can send ‘messages’
that determine the method used on its contents. myArray has three methods defined,
addr:, at:, and to:, which have the method selectors 1, 2 and 3.
This example showed you one aspect of object-orientation, encapsulation of the
data structures: you access the object’s data by an interface given by the messages that
are sent to it. No other access would be possible (although in this case it is easy to
circumvent that restriction, if one does it deliberately). The other aspect - not
covered by the example - is inheritance of methods and data structures: we also need
super- and subclasses, automatic message passing to classes further up in the
hierarchy, method override, and so on.
Also, the example I gave resolves method references at run time (‘late binding’).
This takes time, and if message and object are already defined at compile time, the
compiler should resolve the reference so that the code generated for i at: myArray does
not take any longer than a simple indexed fetch (like myArray i 4 * + @). This case is
called ‘early binding’.
Let me now describe the three projects of object-oriented extensions for Mach2
that I’m aware of and their basic differences.
Object Oriented Extensions for Mach2
One attempt to create a NEON-like environment to Mach2 came from Aleksey
Novicov, of Palo Alto Shipping, who developed a preliminary version of his object
oriented system, called OPEX, whose syntax is very NEON-like. Following parts of
Aleksey’s description of OPEX:
Brief Introduction to OPEX (v0.50):
An Object-oriented Programming Extension for MACH 2
Aleksey Novicov
OPEX contains all of the elements of an object-oriented programming
environment. This includes the ability to define CLASSES, public OBJECTS of various
classes, INSTANCE VARIABLES, and METHODS that are called by SELECTORS. Also, a
class can be defined as having a SUPER CLASS,and thus inherit all of the data
structures and methods of that super class. All of the method/object binding is
currently static only (i.e., only compile-time binding, no run-time binding yet).
Two new vocabularies are present called OBJECTS and IVARS. In normal
operation no special consideration need be given to these vocabularies. However, if any
public objects are to accessed, then the OBJECTS vocabulary must always be present in
the search order.
This a list of words that currently are available in OPEX:
:CLASS ;CLASS ;M :M
BYTES
MW@ SEGMENT PERMANENT INITALL
(abs)
Also, the following MACH 2 words have been enhanced to work with OPEX:
WORKSPACE NEW-SEGMENT TURNKEY
There are many things that still need to be implemented. Some of the obvious
include dynamic binding, support of variable length ARRAYs, and dynamic object
allocation on the heap. Also, the special objects, SELF and SUPER, still need to be
implemented.
More extensive error handling will be implemented to aid the programmer.
Hopefully, OPEX will become more robust as time goes on without sacrificing speed.