The Forth Paradigm

Note:
There is extensive use of “Tooltips” text to support learning which do not seem to render on a Smartphone
Therefore this site is best viewed via a computer’s HD monitor

Previous Section: What is Forth?

Paradigm: “a model of something, or a very clear and typical example of something” Cambridge Dictionary

Forth was conceived and developed on mainframe computers by Charles Moore and his associates ¹ towards the end of the 1960’s and throughout the 1970’s. During the 1970’s Forth was ported to a number of microprocessors by members of the Forth Interest Group (FIG 2007)

1. Embrace Simplicity!

“Charles Moore is one of the greatest software developers ² The ‘Forth’ language he invented is still in use today, particularly by NASA, and has never been bettered for instrumentation and process control. He still argues persuasively that the only way we can develop effective software quickly is to embrace simplicity. Like Niklaus Wirth, he remains a radical whose views have become increasingly relevant to current software development…“ (Morris 2009) (My emphasis)

Extensibility is a major Forth feature   Image#1: (Husband 2011), based on (Moore 1981, p. vii)

In fact, the way you “program” an application in Forth is to create word definitions to extend the Forth language set…

“Computer programming is a form of art, far from being a discipline of science or engineering. For a specified programming problem, there are essentially an infinite number of solutions, entirely depending upon the programmer as an artisan. However, we can rate a solution by its correctness, its memory requirement, and its execution speed…“

“A solution by default must be correct. The best solution has to be the shortest and the fastest…“

“The only way to achieve this goal is to use a computer with an instruction set optimised for the problem. Optimisation of the computer hardware is clearly impractical because of the excessive hardware and software costs. Thus one would have to compromise by using a fixed, general purpose instruction set offered by a real computer and its language compiler. To solve a problem with a fixed instruction set, one has to write programs to circumvent the shortcomings of the instruction set“   Source: (Ting 2013, p. 10) (My Emphasis)

The Forth approach to programming
Image#2: (Husband 2011), based on (Ting 2013, p. 10)

“Forth as a programming language allows programmers to be more creative and productive, because it enables them to mould a virtual computer with an instruction set best suited for the problems at hand. In this sense, Forth is a revolutionary development in the computer science and technology”   Source: (Ting 2013, p. 10)

So to put it another way, a problem is solved in Forth by extending the Forth word-set in contrast to C or all other high-level languages which force you to fit the problem into the word-set and to the syntax ³ of the language being used…

More on this later…

Charles Moore: Keep it Simple! (Hooker n.d) (Leveson 1992)
Image#3: (Husband 2011), based on (Moore 1981, p. vii)

A Simple Choice!

Complexity or Simplicity?
Image#4: (Brodie 1981, p. 312)

Reject Complexity!

Resist the Pressures - Reject Complexity…   Image#5: Based upon (Brodie 1981, p. 67)

2. Design First!

“Forth is a design language. To the student of traditional computer science, this statement is self-contradictory. ‘One doesn’t design with a language, one implements with a language. Design precedes implementation…’ Experienced Forth programmers disagree. In Forth you can write abstract, design-level code and still be able to test it at any time by taking advantage of decomposition into lexicons ⁴ A component can easily be rewritten, as development proceeds, underneath any components that use it. At first the words in a component may print numbers on your terminal instead of controlling stepper motors. They may print their own names just to let you know they’ve executed. They may do nothing at all ⁵ Using this philosophy you can write a simple but testable version of your application, then successively change and refine it until you reach your goal”
(Brodie 2004, p. 31) (My emphasis)

3. Develop from a Prototype (with little planning)

Moore and Brodie take their approach further so that the various processes become a method of problem-oriented solution thinking In essence:

Develop from a Prototype   Image#6: (Husband 2011), based on (Morris 2009)

There are some advantages in this approach – you very quickly create a working application prototype of some kind to show your stakeholders and then you can develop this prototype ⁶… Run on prototype hardware too, until/while “real” hardware platform is being designed/developed… However, the analysis of the problem and the initial starting design must be sound…

4. The Forth Modus Operandi

Forth is an “Interpretive Compiler”

So normally Compiling (“Defining”) Words will create entries in the Dictionary linked-list…

And that is all it will do and what exectly is placed into the definition of the new word is determined by the defining word’s “Compile-Time” behaviour

Later the new word ⁷ created in the dictionary can be run (“executed”) ⁸ and what happens then is determined by the new word’s “Run-Time” behaviour

So Compiling (“Defining”) words have two separate and distinct behaviours and so internally are in two parts:

• Compile-Time
• Run-Time

A detailed discussion of Forth Compilers

Interpreter

“An interpreter for a source language accepts the source language as input and executes it directly. It does not produce a target language but translates directly to an action. A pure interpreter will analyse a source language statement each time it is executed”    (Loeliger 1981, p. 2)

Forth regards interpreters in a radically different way… And employs two different interpretation scenarios…

A detailed discussion of Forth Interpreters

Compiler

Forth regards compilers in a radically different way…

A detailed discussion of Forth Compilers

The Basic Idea

Forth is expressed in words and numbers and is separated by spaces ⁹, i.e.:

These commands may be typed directly from the keyboard or edited onto mass storage and loaded
All words, whether included with the system or user-defined, exist in the “Dictionary”, a singly linked list

A “defining word” is used to add new words to the dictionary. One defining word is   :   (pronounced “colon”), which is used to define a new word in terms of previously defined words. Here is how one might define a new word called LIFT

(1)   The Colon Compiler

The Colon Compiler is invoked by using the Forth Defining word   :   (pronounced “colon”)

(2)   A New Forth App Word is Created

A new Forth Application Word called LIFT is going to be created at the top of the Forth Dictionary

(3)   Terminating the New Word Definition

By invoking the Forth Word   ;   (pronounced “Semi-Colon”), the Colon Definition of the new application word LIFT is terminated (“ended”, “completed”)

The Forth system is no longer adding dictionary content and the Forth system resumes being interpretive

The new word LIFT may now be used instead of the long sequence of words that comprise its definition

Forth words can be nested like this indefinitely and writing a Forth application consists of building increasingly powerful definitions, such as this one, in terms of previously defined words
(The whole section is based on (Brodie 2004, p. 266)

Implicit Calls

To execute (or “run” or “invoke”) the word   LIFT   for instance, you don’t have to say   CALL LIFT   you just type   LIFT   or it is encountered in the input stream and is invoked

Implicit Data Passing

Passing data in Forth is implicit and is achieved via Forth’s Parameter Stack, which in most implementations is the microprocessor’s stack. However, there are no PUSH or POP operations in high-level Forth ¹⁰

The implications of Implicit Calling and Implicit Data Passing

As data is passed implicitly, we are relieved of the act of passing data to and from our code, leaving us to concentrate upon the functional steps of the data’s transformation…

Passing data via a stack has the advantage that words can nest within words, because any word can put numbers on the stack and take them off without upsetting the flow of data between words at a higher stack level ¹¹ In this way, the stack supports structured, modular programming while providing a simple mechanism for passing local arguments

Forth eliminates from our programs the details of how words are invoked and how data is passed
What does that leave? Only the words that describe our problem…

Having words, we can fully exploit the recommendations of (Parnas 1972) ¹² – to decompose problems according to things that may change, and to have each module consist of many small functions, as many as are needed to hide information about that module ¹³ Forth allows us to write as many words as we need, no matter how simple they may be…
(All text in these sections is based on (Brodie 2004, pp. 18-20) (My emphasis)

Programming with Components (“Objects”)

Having a large set of simpler words makes it easy to use a technique that Brodie calls “component programming” He defines a component as “the smallest set of interacting data structures and algorithms that share knowledge about how they collectively work…“ (Brodie, 2004, p. 20) In reality, they are just a collection of well-chosen and well-designed Forth words…

A component represents a resource which can be a piece of hardware such as a UART, or a software resource such as a queue or an object, and all components will involve data objects and algorithms

Brodie calls the Forth words that make up the component, the “Lexicon”. The design of the lexicon is very important as the essence of a Forth application is the creation of the appropriate problem-solving set of words as an extension to the core set of Forth words

An example Forth Application’s Lexicon & associated Component
Image#7: Based on (Brodie 2004, p. 22)

Forth is word-based, so a real Forth application consists of a number of small words all working together to provide a functionality set. These words represent the various components defined, identified and documented during the analysis and design process (See next section)

The Entire Application Consists of Components represented by Lexicons
Image#8: (Brodie 2004, p. 23)

5. Problem-oriented Solution Thinking

Brodie suggests nine phases to this problem-oriented solution thinking activity:

The Nine Development Phases
Image#9: Based on (Brodie 2004, p. 38)

5.1 Iteration - The Scientific Method

The Scientific Method
Image#10: Based on (Brodie 2004, p. 39) citing (Harris 1981)

5.2 The Iterative Approach to Development

An Iterative Approach to Development
Image11: (Husband 2011), modified from (Brodie 2004, p. 39) citing Harris (Harris 1981)

The scope of this iterative cycle can apply to the whole project and then down to each individual Forth word in the application’s lexicon and it can also be applied to the design and implementation of any hardware needed

5.3 The Iterative Approach to Analysis

Referring to the image above, Brodie breaks down the “Analyse Problem” phase into another iterative cycle, shown below

An Iterative Approach to Analysis
Image#12: (Brodie 2004, p. 48) citing (Harris 1981)

You start this whole process by following the method outlined below by Harris (and reflected above in the previous two images)

5.4 Start with the Simplest Solution & Few Constraints

Develop with very few initial constraints
Image#13: (Brodie 2004, p. 40) citing (Harris 1981)

6 The Importance of the Conceptual Model of the Proposed Solution

It must be self-evident that if the conceptual model of the solution is incorrect and/or deficient then the whole project may not be viable

6.1 The Conceptual Model is Forth…

As far as the software is concerned, the application is not “written in Forth”
Forth IS the application

The language is extended as required, to contain word sets (“Lexicons”) which describe and implement the chosen functions and solutions… ¹³

6.2 Some Tips when Developing the Conceptual Model

Tips for Developing the Conceptual Model
Image#14: All points from (Brodie 2004, pp. 48-65)

Important Note

The following sections, 7 to 11, are what David Husband suggests should be part of the Forth Paradigm !!
(All based upon the work of (Flynt 2004))

7. Beginning the Design

Flynt’s view of the elements of the Design
Image#15: (Flynt 2004, p. 124)

This is where the UML has a role as this can all be entered as a model in a UML Tool such as Enterprise Architect

8. Architecture versus Design

It is important to have a clear idea of the architecture (conceptual model) before doing too much design work

The overlap between Design & Architecture
Image#16: (Flynt 2004, p. 125)

8.1 Identify Design Elements

This is all to do with identifying and specifying Objects (“components”) and their relationships

Identifying the fundamental elements of the Design
Image#17: (Flynt 2004, p. 126)

8.2 Principles of Design

And even more object-oriented analysis and discovery…

Establish Design Principles
Image#18: (Flynt 2004, p. 127)

9. Designing for Quality

Quality design reduces software lifetime costs…
Image#19: (Flynt 2004, p. 133)

Of course, the points in the image above are actually the non-functional requirements which should be very carefully specified so that they are testable and traceable

A detailed discussion of Software Quality

10. Use Design Tools

Basic Design Tools are used to generate objects & relationships
Image#20: (Flynt 2004, p. 136)

11. The Importance of the Unified Modelling Language (“UML”)

It can be seen from above, the Analysis Cycle contains at least two stages where the UML must be involved:

• Stage 1: Elicit the Requirements – Document them with UML – Create Specifications
• Stage 2: Describe the Conceptual Model – Create a Documented Model in UML

12. Forth Typing

What on earth is “Typing” ??!! (Within a Software Language context !!)

“a type system is a logical system comprising a set of rules that assigns a property called a ‘type’ to the various constructs of a computer program, such as variables, expressions, functions or modules […]”   Source: Wikipedia

It is often claimed that Forth is an “untyped” language… This is not really true !!

A detailed discussion of typing within a Forth context…

13. That “No Floating-Point” Nonsense…

Some people seem obsessed that Forth does not support “floating-point” numbers as standard…

The author has been using Forth for over 40 years without ever needing “floating-point” arithmetic, finding 32-bit fixed-point arithmetic and scaling to be perfectly adequate…

A detailed discussion of scaling…

14. That “Reverse Polish” Nonsense…

Forth is a simple stack machine that implements a very simple parser, so the use of Reverse Polish is inevitable with that parser…

“Postfix Expressions”:
Some people seem obsessed that the default Forth parser uses Reverse Polish Notation (“RPN”)…

In English we say “Red House”; in French they say “Maison Rouge” – “House Red”….
Reverse Polish Notation is quite a straightforward way of operating and makes quite a few things much easier… Remember: Complexity or Simplicity?

A detailed discussion of the default Forth parser…

A detailed discussion of Forth’s Reverse Polish Notation…

Important Note

From here onwards, when we refer to Forth, we mean figForth !!

Next Section: The figForth Paradigm

References:

Biancuzzi, F. and Warden, S., 2009. Masterminds of Programming.

Brodie, L., 1981. Starting FORTH : an introduction to the FORTH language and operating system for beginners and professionals [online]. Englewood Cliffs, N.J: Prentice-Hall. Available from: https://www.forth.com/starting-forth/.

Brodie, L., 2004. Thinking Forth - A Language and Philosophy for Solving Problems (3rd Ed). Available from: http://sourceforge.net/projects/thinking-forth/files/reprint/rel-1.0/thinking-forth.pdf/download.

FIG, 2007. Forth Interest Group. Available from: http://www.forth.org/.

Flynt, J., 2004. Software Engineering for Game Developers.

Harris, K., 1981. The Forth Philosophy.

Hooker, D., n.d. Keep It Simple. Available from: http://wiki.c2.com/?KeepItSimple.

Husband, D., 2011. M.Sc in IT (Software Engineering). Master’s thesis. University of Liverpool.

Leveson, N. G., 1992. High-Pressure Steam Engines & Computer Software. Available from: http://sunnyday.mit.edu/steam.pdf.

Loeliger, R. G., 1981. Threaded Interpretive Languages - Their Design and Implementation [online]. Available from: Http://figforth.org.uk/library/R. G. Loeliger__Threaded.Interpretive.Languages.pdf.

Moore, L., CH via Brodie, 1981. Foreword to: Starting FORTH. Englewood Cliffs, N.J: Prentice-Hall.

Morris, R., 2009. Interview with Chuck Moore: Geek of the Week. Available from: http://www.simple-talk.com/content/print.aspx?article=775.

Parnas, D. L., 1972. On the Criteria To Be Used in Decomposing Systems into Modules. Available from: http://figforth.org.uk/library/p1053-parnas.pdf.

Ting, C. H., 2013. Systems Guide to fig-Forth [online]. 3rd ed. San Mateo, CA 94402, USA: Offete Enterprises, Inc. Available from: http://figforth.org.uk/library/Systems.Guide.to.figForth.pdf.