Forth lecture 15.

Structures and classes in Forth.

The disadvantages of the old stuff.

BUILDS DOES was one of the first object oriented stuff ever (pre 1975).

It has it inside out.


CREATE makes a header, then its data is filled, then it is bestowed with some action.

Fundamental problems:

All structs defined in Forth copy object oriented concepts in an unForthy way, because they make a distinction between data (fields) and methods (code). But of course a field is merely a method that puts an address on the stack. We will see that it is the default action, comparable to a

that is followed immediately by a semicolon.

The correct approach.

If we turn


inside out we get the more correct

0 \ Sample input.
M: CONTENT @ M;   ,

This generalizes to

0 0 \ real, imaginary
M: REAL-PART @ M;        ,

This is in contrast with the CREATE DOES construct that doesn't bear generalizing. It is also in contrast with the oo en vogue, in that there is no distinction between data and methods. A smart field is just some action working on an offset in a data structure.

The usage of COMPLEX is


So Z makes this the current object (by filling in a pointer ^COMPLEX) and REAL-PART adds a known offset to this pointer, then does its thing. The second Z can be left out.

The definition of Z requires some class dependent data, in this case 1 and 2. The data to build the data structure is to be supplied during the definition of the class too. This is such that a trial build can take place and the offsets of the fields can be determined.

At first sight it may seem that the requirement to make objects current is AK ward, but in practice it isn't too bad. I can testify that this is a viable and productive way to handle structures. It was very successful in my rewrite of the manx package. It was also instrumental in my ciasdis project.

At first I used still the old syntax as follows

struct aap

It may be less neat but functionally equivalent, but the interesting point is that structures in Forth automatically become classes.

BUILDS DOES> had the useful property that because there was just one method there was no need to specify the smart field.

In order to have this we could have a M:DEFAULT

This generalizes to

M:DEFAULT 2@ ;        2,



The default field is automatically executed when the object is used. This makes it however impossible to not have that action, if you only need some other method of the class. I am somehow convinced that using colors in color Forth works out very pleasantly, because the same word can have more than one action depending on its color.

Implementation notes.

In the implementation I have currently, a dummy object of the class is build once during compilation, and during that building the offsets are collected. This means that words like the comma in the above example are executed as well as compiled. For this purpose some code is temporarily stored in strings. This sound horrendous. However the whole class facility costs two screens, not bad for ISO Forth. For reference they follow in the next section.

Reference ISO implementation

This is the implementation of class endclass. It is still mimics the CREATE DOES< construction. My ministring package is of the essential.

( M: auxiliary_for_class ) \ AH A4nov26
CREATE NAME$ 128  ALLOT         \ The name of the struct.
CREATE CRS$ 4096 ALLOT          \ Evaluate buffer, general.
VARIABLE LAST-IN                \ Start of interpreted code
VARIABLE DP-MARKER              \ Start of alternative dict.
: !IN   IN @ LAST-IN ! ;        \ Remember last value of ``IN''
: IN$  LAST-IN @ IN @  OVER - ; \ Return input STRING since !IN
: itoa   0 <# #S #> ;           \ Transform an INT to a STRING.
\ Compile "method" working on addres with offset.
    CREATE M$ 256 ALLOT         \ Evaluate buffer, method.
: M:   IN$ 3 - CRS$ $+!   "^" M$ $!   NAME$ $@ M$ $+!
   " @ " M$ $+!   HERE DP-MARKER @ - itoa M$ $+!   " +" M$ $+!
   SWAP-DP   :   M$ $@ EVALUATE ;
\ End compiling a method.
( class endclass ) \ AH A4jun16
: +NAME    NAME$ $@ CRS$ $+! ;  \ Add the name.
: +NAME+$   +NAME   CRS$ $+! ;  \ Add the name and a STRING.

\ Define class "name". Compile this-pointer, start build-word.
: class   NAME NAME$ $!   "VARIABLE ^" CRS$ $!
   +NAME   CRS$ $@ EVALUATE   ": BUILD-" CRS$ $!
   " HERE >R " +NAME+$   SWAP-DP   HERE DP-MARKER !   !IN ;

\ Recover memory, compile build-word and class-word.
: endclass   ?EXEC   DP-MARKER @ HERE - ALLOT   SWAP-DP
   IN$ 9 - CRS$ $+!   " R> ;" CRS$ $+!   CRS$ $@ EVALUATE
   ": " CRS$ $!   " CREATE BUILD-" +NAME+$   " ^" +NAME+$
   " ! DOES> ^" +NAME+$   " ! ;" +NAME+$   CRS$ $@ EVALUATE ;

For colorforth we would have to use two new colors probably. A new color is needed be for defining a class, the red, yellow and green colors are for defining, execution and compilation of fields and a separate color again for the default action.

This is how it would look:

<orange>COMPLEX   ( a class)
<red>REAL-PART <yellow>@        <green>,
<red>IMAGINARY-PART <yellow>@   <green>,

The red color is used with a class name to define a word from that class. ( How to end a class is yet unclear or maybe we need a ; here.)

Washer example

The washer example is famous for it supposedly demonstrates that good Forth code needs no comment. It show how to program a washing machine. This is an object oriented version of the code for lina or wina version 4.x.x. For newer versions of ciforth you may need to preceed it with
   WANT -legacy-

  • Other Forth lectures
  • Go to the home page of Albert van der Horst