On Standardizing Object-Oriented Forth Extensions

Standardization and Libraries

Andrew McKewan argues that we need to agree on (i.e., standardize) one model to start building an object-oriented library. My view is just the reverse: If someone writes a good object-oriented library that everyone wants to use, we will all use the object model on which that library is based; that model will become a de-facto standard and finally a de-jure standard.

Andrew McKewan uses the Forth scientific library (FSL) as example. He argues that it was necessary to standardize floating-point in ANS Forth before the FSL could be written. Even if that were true (of which I am not convinced), the cases differ significantly: A floating-point implementation written in Forth-83 would have been unacceptably slow for many purposes; OTOH, many object-oriented models can be implemented in standard Forth efficiently enough to be useful. (BTW, this is a major strength of Forth over many other languages: C, Pascal, Ada etc. require language changes and new compilers to accomodate object-oriented programming; in Forth every programmer can do it.)

As a counter-example, consider the case of locals: Even though the commitee standardized the syntax LOCALS| this read can you |, many people use the syntax { you can read this }. This syntax can be implemented without performance penalty in standard Forth ([hayes92], http://www.complang.tuwien.ac.at/forth/anslocal.fs).

What would such an object-oriented library look like? It should have as few system dependences as possible. This excludes libraries for dealing with windowing systems, which appear to be the most popular application of object-oriented technology in Forth. The library should deal with problems that are hard enough to make reinventing the wheel unattractive. A look at the standard libraries of other object-oriented languages should provide some inspiration.


The major problem with standardizing an object-oriented model by agreeing on one is that there is no consensus. There was a discussion of this topic on comp.lang.forth (Subject: Objects for ANS Forth) in August 1996. [rodriguez&poehlman96] lists 17 object-oriented extensions for Forth, and this does not include several that were discussed on comp.lang.forth.

OTOH, what's so bad about having no standard object model? We don't have a standard array or structure model, either, because we can build what we need when we need it, at little cost.

The Neon Model

I cannot create a synopsis of the complete discussion, therefore I'll restrict myself to the points relevant to the Neon/Yerk model (as presented in [mckewan97]), which is also implemented in Mops, Win32Forth and in ANS Forth [mckewan97] (as presented in [mckewan97]). This model currently (in 1998) appears to be the most popular one. The points under discussion were: We can make the Neon model standard (after all, we can still implement the others in plain Forth), but if we do so, we should be aware of its properties.


[diwan+96] Amer Diwan, J. Eliot B. Moss, and Kathryn S. McKinley.
Simple and effective analysis of statically-typed object-oriented programs. In Conference on Object-Oriented Programming Systems, Languages \& Applications (OOPSLA '96), pages 292-305, 1996.
[hayes92] John R. Hayes.
User-defined local variable syntax with ANS Forth. SigForth Newsletter, 4 no. 2, 1992.
[mckewan97] Andrew McKewan.
Object-oriented programming in ANS Forth. Forth Dimensions, March 1997.
[rodriguez&poehlman96] Bradford J. Rodriguez and W. F. S. Poehlman.
A survey of object-oriented Forths. SIGPLAN Notices, pages 39-42, April 1996.
[vitek&horspool96] Jan Vitek and R. Nigel Horspool.
Compact dispatch tables for dynamically typed object oriented languages. In Tibor Gyim\'othy, editor, Compiler Construction (CC'96), pages 309-325, Link\"oping, 1996. Springer LNCS 1060.