LETTERS

Example 1 shows a Mops coding example that's very short because it conveniently already has number (var) and point classes that respond in a meaningful way to a print message (print:). Example 1 shows how the point class might be defined in Mops.

Doug Hoffman

CompuServe 72310,1743

Dear DDJ,

I read your October 1993 issue with great dismay--here is an issue ostensibly devoted to object-oriented programming languages that does not mention Oberon-2. I am disturbed because: 1. Somehow Oberon-2 was not selected for illustration; and 2. it was not even mentioned in the discussion of OOP languages. While I understand that there are many such languages and that in depth coverage of all would likely be impossible, I am puzzled since some of the languages you did see fit to cover probably do not have a volume of written code comparable to that of Oberon-2. Several excellent code examples as well as the Oberon operating system illustrate the capabilities of this well-thought-out evolution of structured, modular programming languages.

Also not included was Modula-3. It is distressing that in the article, "Comparing Object-Oriented Languages," Ada is used to provide an approximation of the doubly linked list example. Modula-3 would have been, in my opinion, a better choice. In fact, there is an excellent set of software components that includes the doubly linked list case, but also provides iterators and the like for accessing and operating on this list of possibly heterogeneous node types: It is written with Modula-2! (The Modula-2 Software Component Library, C. Lins, Springer-Verlag.)

The second matter that concerns me is the lexicon that has developed in the object-oriented programming arena. I have difficulty when simple concepts such as type extension and procedure variables (and their combinations) become mired in terminology that largely obscures rather than describes or defines. I will agree that OOP comes into its own under large, complex system conditions and certainly impacts program design in a fundamental manner, but then this is analogous to the effect on programming that record, enumeration and pointer types, and structured-programming constructs had at their introduction. Unfortunately, in the case of object-oriented programming languages, we are speaking of enhancements to existing concepts, principally type extension and broad use of procedure variables, rather than the introduction of new concepts. Yet these relatively simple (and powerful) notions are confounded or lost in the egregious sea of OOP-speak.

Perhaps I must simply give in and recognize that we (in the U.S., anyway) are living in a "mono-C-istic'' programming society. I hope, however, that this is not, and will not be the case.

Michael A. McGaw

Fairview Park, Ohio

DDJ responds: Our thanks to the many readers who wrote in with similar concerns about the coverage of so-called "obscure'' languages like Drool, Beta, Sather, and Parasol. Because space considerations prevent analysis of every object-oriented language in a single issue, the October issue provided a cross-section with special attention given to nonproprietary languages. In particular, Drool and Parasol are in the public domain with complete source code available in the DDJ Forum on CompuServe.

Now On To Forth_

Dear DDJ,

Forth is an extensible language but Michael Swaine's example in DDJ (November 1993) doesn't extend Forth any more than writing a function extends C. Extending a language would be like adding the syntax:

LOOP
_
EXIT  IF  (condition)
_
ENDLOOP

to Fortran or making complex a new elementary data type in C with exactly the same standing as int --reserved word and all.

The syntax of Forth is extremely simple: "Words'' are character strings delimited by whitespace. The semantics of Forth are simple, too; nearly all words are imperative verbs:

Some few "defining'' words add words to the dictionary, so the first time a user-defined word appears, the defining word puts it in the dictionary.

Thereafter, the newly defined word is an imperative verb.

A few "immediate" words are executed during compilation.

Most words are not executed during compilation--they are "compiled" into the dictionary during compilation.

Because of these two simplicities, the Forth compiler can be exposed to the programmer. (The source code for the fig-Forth text interpreter, compiler, and keyboard debugger fits on a screen of 16 lines of 64 characters with plenty of whitespace.) Extending Forth consists of defining: 1. new immediate words which have a compile-time effect, and 2. new defining words.

A truly marvelous feature of Forth allows the programmer to specify the compile-time effect of new defining words and the run-time effect of words defined by the new defining word. The corresponding chore in, for example, C would require:

Defining the new syntax so that it isn't ambiguous and doesn't conflict with existing syntax (nontrivial).
Defining the semantics of the new syntax (pretty easy).
Altering the parser and diagnostics of the compiler to recognize and diagnose the new syntax (without impact on parsing or diagnosing old syntax!).
Altering the code generator so that the new target code implements the new semantics (without impacting such things as register usage, optimizers, and so forth).

The fig-Forth text interpreter, keyboard debugger and compiler looks something like Example 2. While some programmers are attracted to Forth by its simplicity and compactness, others are attracted by extensibility. Some of the first object-oriented languages I ever saw were implemented by extension of Forth.

William E. Drissel

Grand Prairie, Texas

Example 1: Mops code sample.

:class point super{ object }  \ begin class definition, superclass is object
    int x   \ declare an instance variable of type integer, named x
    int y   \ declare an instance variable of type integer, named y

:m put:  ( x y -- )      \ begin put: method definition. x, y passed via Forth stack
    put: y   \ use put: methods of the int ivars to store values from stack
    put: x
;m  \ end method definition

:m get:  ( -- x y )  \ stuff between parentheses is just a Forth stack picture
     get: x  \ x and y will be "gotten" to the Forth stack, ready for any use
     get: y
;m

:m print:
    get: self . . \ finally, we actually use some Forth, the dot (.) to print
;m

;class  \ end class definition

Example 2: A Forth interpreter, compiler and debugger, in pseudocode.

forever {
     get the next word (delimited by whitespace)
     look it up in the dictionary
     if found
          if we are compiling
               if the word is immediate
                    execute the word
               else
                  "compile" the word into the dictionary
          else
               execute the word
     else //(not found, must be a number or undefined)
          if it's a number
               "compile" a literal into the dictionary
          else
               send word followed by "?" to screen
               stop compiling
               flush interpreter into buffer
}  // end of forever