This page (revision-4) was last changed on 03-Feb-2023 15:21 by Carsten Strotmann 

This page was created on 25-Apr-2010 20:23 by Carsten Strotmann

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note
4 03-Feb-2023 15:21 35 KB Carsten Strotmann to previous
3 25-Apr-2010 20:37 35 KB Carsten Strotmann to previous | to last
2 25-Apr-2010 20:28 36 KB Carsten Strotmann to previous | to last
1 25-Apr-2010 20:23 36 KB Carsten Strotmann to last

Page References

Incoming links Outgoing links
What is Forth
What is Forth

Version management

Difference between version and

At line 5 added 2 lines
(this text seems to be coming from the old F-PC homepage, and might be written by [Tom Zimmer|http://tomzimmer.blogspot.com/], the Author of F-PC and other great Forth Systems)
At line 75 changed 9 lines
Depending on who you talk to " or believe " Forth is a lan-
guage, an environment, an operating system, and a philosophy
of programming. All these claims are true, in some sense,
but this semantic overload of the term Forth sometimes gives
"outsiders" the sensation of being smothered in cotton wool
when they try to understand what Forth is about. It doesn't
help matters that Forth programmers use a unique " and some-
what bizarre " terminology when discussing how the language
works and is structured.
Depending on who you talk to " or believe " Forth is a language, an environment, an operating system, and a philosophy of programming. All these claims are true, in some sense, but this semantic overload of the term Forth sometimes gives "outsiders" the sensation of being smothered in cotton wool when they try to understand what Forth is about. It doesn't help matters that Forth programmers use a unique " and somewhat bizarre " terminology when discussing how the language works and is structured.
At line 85 changed 9 lines
Every Forth language element that can be used interactively
or within a program is called a 'word'. (The term' word' is
also severely overloaded in Forth literature; in some con-
texts it can mean merely "a blank-delimited token from the
input stream," and there is also a parsing operator named
WORD). The source code for a particular word is called its
'definition'. Some words are 'primitives', coded in the
CPU's native machine language, the remainder are' high level
or secondary definitions', coded in Forth itself.
Every Forth language element that can be used interactively or within a program is called a 'word'. (The term' word' is also severely overloaded in Forth literature; in some contexts it can mean merely "a blank-delimited token from the input stream," and there is also a parsing operator named WORD). The source code for a particular word is called its 'definition'. Some words are 'primitives', coded in the
CPU's native machine language, the remainder are' high level or secondary definitions', coded in Forth itself.
At line 95 changed 8 lines
The Forth interpreter/compiler looks words up in the' dicti-
onary', which is essentially a symbol table that associates
each word's name with the address of the corresponding exe-
cutable code. The dictionary can be subdivided into' vocabu-
laries' that can be searched independently or in a tiered
fashion; this allows names to be overloaded and also allows
"dangerous" or infrequently used words to be "hidden" so
that they are not invoked accidentally.
The Forth interpreter/compiler looks words up in the' dictionary', which is essentially a symbol table that associates each word's name with the address of the corresponding executable code. The dictionary can be subdivided into' vocabularies' that can be searched independently or in a tiered fashion; this allows names to be overloaded and also allows "dangerous" or infrequently used words to be "hidden" so that they are not invoked accidentally.
At line 104 changed 13 lines
Why do we concern ourselves with this strange nomenclature
at all? For the purely pragmatic reason that to communicate
with a Forth programmer, you need to use his terminology,
because he probably won't understand yours. Terms like
'word', 'dictionary', 'vocabulary', and 'definition' have
the force of "tradition" behind them and pervade every Forth
book, article, and set of source code in existence. Further-
more, many Forth programmers are self-taught, learned Forth
only as a means to accomplish something else, and have never
used any other programming language. Backgrounds in electri-
cal or mechanical engineering, medicine, natural languages,
music, astronomy, and the like are common; formal educations
in computer science or mathematics are rare.
Why do we concern ourselves with this strange nomenclature at all? For the purely pragmatic reason that to communicate with a Forth programmer, you need to use his terminology, because he probably won't understand yours. Terms like 'word', 'dictionary', 'vocabulary', and 'definition' have the force of "tradition" behind them and pervade every Forth book, article, and set of source code in existence. Furthermore, many Forth programmers are self-taught, learned Forth only as a means to accomplish something else, and have never used any other programming language. Backgrounds in electrical or mechanical engineering, medicine, natural languages, music, astronomy, and the like are common; formal educations in computer science or mathematics are rare.
At line 118 changed one line
$ 3. 'The Forth Language'
!'The Forth Language'
At line 120 changed 19 lines
Viewed strictly as a language, Forth is clearly in the camp
of the modern, structured languages such as C, Pascal, and
Modula II. It has all the proper flow of control constructs
and, unlike C, does' no't have a GOTO. Like C, but unlike
Pascal and Modula II, Forth draws no distinction between
procedures and functions. A more important difference betwe-
en Forth and the other structured languages is that Forth
has no support for data typing either at compile time or at
runtime. The key difference between Forth and the other
structured languages is that the Forth compiler is 'extensi-
ble'. Forth allows the programmer to declare new data types
'and' allows him to define new compiler keywords (such as
control structures) and then use them immediately " even wi-
thin the very next procedure. Forth even has a compiler fa-
cility for creating new kinds of language' objects', if you
will: the programmer can separately define what happens at
compile time (when the object is instantiated) and what hap-
pens at runtime (when the object is invoked). The closest C
comes to being extensible is to allow you to build record
Viewed strictly as a language, Forth is clearly in the camp of the modern, structured languages such as C, Pascal, and Modula II. It has all the proper flow of control constructs and, unlike C, does not have a GOTO. Like C, but unlike Pascal and Modula II, Forth draws no distinction between procedures and functions. A more important difference between Forth and the other structured languages is that Forth
has no support for data typing either at compile time or at runtime. The key difference between Forth and the other structured languages is that the Forth compiler is 'extensible'. Forth allows the programmer to declare new data types 'and' allows him to define new compiler keywords (such as control structures) and then use them immediately " even within the very next procedure. Forth even has a compiler facility for creating new kinds of language' objects', if you will: the programmer can separately define what happens at compile time (when the object is instantiated) and what happens at runtime (when the object is invoked). The closest C comes to being extensible is to allow you to build record
At line 141 changed 19 lines
But Forth is not simply a set of keywords and syntax rules,
it is a description of a virtual machine. The most important
aspect of the virtual machine is that it has exactly two
stacks: a parameter stack and a return stack. Nearly all
Forth words use the parameter stack for both their arguments
and their results; the return stack is used for flow of con-
trol within a program and (occasionally) for temporary sto-
rage of working values. Forth lends itself naturally to re-
cursive algorithms because of this stack-based architecture;
in "classic" Forth programming, global variables are frowned
on and rarely used. The extant Forth standards specify the
names and actions of less than 200 words, which suffice to
define the Forth virtual machine and the behavior of the in-
terpreter/compiler. Commercial Forth development systems are
much more elaborate, and have at least 500 words resident
and available in the interpreter/compiler. Unfortunately, in
many Forth manuals the words are simply documented in ASCII
collating sequence, and are discussed as functional groups
only as an afterthought (if at all). This makes the prospect
But Forth is not simply a set of keywords and syntax rules, it is a description of a virtual machine. The most important aspect of the virtual machine is that it has exactly two stacks: a parameter stack and a return stack. Nearly all Forth words use the parameter stack for both their arguments and their results; the return stack is used for flow of control within a program and (occasionally) for temporary storage of working values. Forth lends itself naturally to recursive algorithms because of this stack-based architecture; in "classic" Forth programming, global variables are frowned on and rarely used. The extant Forth standards specify the names and actions of less than 200 words, which suffice to
define the Forth virtual machine and the behavior of the interpreter/compiler. Commercial Forth development systems are much more elaborate, and have at least 500 words resident and available in the interpreter/compiler. Unfortunately, in many Forth manuals the words are simply documented in ASCII collating sequence, and are discussed as functional groups only as an afterthought (if at all). This makes the prospect
At line 162 changed 27 lines
Actually, 500-600 language elements is almost exactly the
same as the combined number of operators, keywords, and run-
time library functions in Microsoft C or Borland C++, and
you can study Forth 'initially' with much the same approach
as you would use for C. As a first approximation, you can
view the relatively few "magic" words known to the Forth co-
mpiler as the "language," and treat the rest as a runtime
library divided into functional categories such as stack
operators, arithmetic/logical operators, memory access ope-
rators, and so on. As with any language, you will use 10% of
the library 90% of the time, so you can just learn the most
common functions first, and look up in the rest in the manu-
al when you need them. Once you've got a basic grasp of
what's available in the Forth language, it's better to think
about the system using a "layered" model, because this is
the way the system is actually built up. The lowest layer
consists of the primitives, which are written in the assem-
bly language of the host CPU and implement the Forth virtual
machine. The words coded as primitives tend to be the most
frequently used arithmetic/logical, comparison, stack, and
memory operators along with a few text-parsing building
blocks for the interpreter/compiler. Each additional layer
contains increasingly complex functions built out of the
words defined in the layers below: console I/O, mass stora-
ge, formatting and string management, the interpreter, the
compiler, and at the top, utilities such as the editor and
assembler.
Actually, 500-600 language elements is almost exactly the same as the combined number of operators, keywords, and runtime library functions in Microsoft C or Borland C++, and you can study Forth 'initially' with much the same approach as you would use for C. As a first approximation, you can view the relatively few "magic" words known to the Forth compiler as the "language," and treat the rest as a runtime library divided into functional categories such as stack operators, arithmetic/logical operators, memory access operators, and so on. As with any language, you will use 10% of the library 90% of the time, so you can just learn the most common functions first, and look up in the rest in the manual when you need them. Once you've got a basic grasp of what's available in the Forth language, it's better to think about the system using a "layered" model, because this is the way the system is actually built up. The lowest layer consists of the primitives, which are written in the assembly language of the host CPU and implement the Forth virtual machine. The words coded as primitives tend to be the most frequently used arithmetic/logical, comparison, stack, and memory operators along with a few text-parsing building blocks for the interpreter/compiler. Each additional layer contains increasingly complex functions built out of the words defined in the layers below: console I/O, mass storage, formatting and string management, the interpreter, the compiler, and at the top, utilities such as the editor and assembler.
At line 190 changed 17 lines
Two aspects of Forth that are frequently criticized are its
cryptic names and its postfix ('or reverse Polish') syntax.
To address the former: when the fundamental Forth names were
assigned, 10 character-per-second Teletypes were common and
so were minicomputer systems with 8 or 16 KB of RAM. Conse-
quently, short names were highly desirable to conserve memo-
ry and keystrokes, and we ended up with symbols such as @
for a memory fetch, ! for a memory store, and so on. I won't
make any attempt to defend the historical Forth namings;
each language has its conventions, and Forth's are no stran-
ger than some found in C, LISP, or APL. Readable, maintaina-
ble programs can be written in any language, as can write-
only, unmaintainable programs. The secret of obtaining the
former rather than the latter is good design, discipline,
and documentation, not use of a particular language. At le-
ast in Forth, since it is extensible, you can rename any
language element to anything you like!
Two aspects of Forth that are frequently criticized are its cryptic names and its postfix ('or reverse Polish') syntax. To address the former: when the fundamental Forth names were assigned, 10 character-per-second Teletypes were common and so were minicomputer systems with 8 or 16 KB of RAM. Consequently, short names were highly desirable to conserve memory and keystrokes, and we ended up with symbols such as @ for a memory fetch, ! for a memory store, and so on. I won't make any attempt to defend the historical Forth namings; each language has its conventions, and Forth's are no stranger than some found in C, LISP, or APL. Readable, maintainable programs can be written in any language, as can write-only, unmaintainable programs. The secret of obtaining the former rather than the latter is good design, discipline, and documentation, not use of a particular language. At least in Forth, since it is extensible, you can rename any language element to anything you like!
At line 208 changed 5 lines
The complaints about about Forth's postfix syntax are more
to the point, and deserve a more cogent response. In postfix
systems, the arguments precede the operator; for example, to
add 1 and 2 in Forth you would write:
The complaints about about Forth's postfix syntax are more to the point, and deserve a more cogent response. In postfix systems, the arguments precede the operator; for example, to add 1 and 2 in Forth you would write:
{{{
At line 214 changed one line
}}}
At line 216 changed one line
{{{
At line 218 changed one line
}}}
At line 220 changed one line
{{{
At line 111 added 2 lines
}}}
When recursive descent compilers for C and Pascal parse your pretty infix expressions, they transform the expressions into an intermediate postfix form before generating machine code. Forth is postfix to start with to shift the burden of expression evaluation onto the programmer, so that the compiler can be simpler, smaller, and faster. While postfix notation certainly takes some getting used to, the success of HP calculators indicates that postfix should not be considered a major barrier to learning Forth. It is interesting to note that (because the Forth compiler is extensible) an infix expression evaluator can easily be layered onto the compiler; several have been published, but Forth programmers have apparently not found them necessary or useful.
At line 223 changed 13 lines
When recursive descent compilers for C and Pascal parse your
pretty infix expressions, they transform the expressions in-
to an intermediate postfix form before generating machine
code. Forth is postfix to start with to shift the burden of
expression evaluation onto the programmer, so that the com-
piler can be simpler, smaller, and faster. While postfix no-
tation certainly takes some getting used to, the success of
HP calculators indicates that postfix should not be conside-
red a major barrier to learning Forth. It is interesting to
note that (because the Forth compiler is extensible) an in-
fix expression evaluator can easily be layered onto the com-
piler; several have been published, but Forth programmers
have apparently not found them necessary or useful.ul.
!'The Forth Environment'
At line 237 changed one line
$ 4. 'The Forth Environment'
The C, Pascal, and Modula II languages are typically implemented as native code compilers, and true interpreters for these languages (when they exist at all) are usually slow and cumbersome. Although the so-called integrated environments for these languages, beginning with Turbo Pascal in 1983, have improved programmer productivity immensely, the environments are really just coresident editors, compilers, and linkers with a shell that allows the programmer to jump quickly from one to the other. They are not interpretive environments: you cannot invoke any language element, or a procedure you have written yourself, interactively by typing its name together with some parameters and look at the results.
At line 239 changed 13 lines
The C, Pascal, and Modula II languages are typically imple-
mented as native code compilers, and true interpreters for
these languages (when they exist at all) are usually slow
and cumbersome. Although the so-called integrated environ-
ments for these languages, beginning with Turbo Pascal in
1983, have improved programmer productivity immensely, the
environments are really just coresident editors, compilers,
and linkers with a shell that allows the programmer to jump
quickly from one to the other. They are not interpretive en-
vironments: you cannot invoke any language element, or a
procedure you have written yourself, interactively by typing
its name together with some parameters and look at the re-
sults.
Forth, on the other hand, is the original interpretive, interactive, integrated environment. In typical systems, the editor, assembler, and various debugging utilities are written in Forth itself and are kept resident at all times. The source code for these tools is usually kept on-line, so that the programmer can tune them to his personal taste. Although Forth has been implemented in many ways, the "classic" implementation is an unified interpreter and incremental compiler based on some startlingly simple concepts and ground rules. The core of the interpreter/compiler is a loop which reads blank-delimited tokens from the input stream (which can be either the keyboard or blocks of text from mass storage); the disposition of each token is controlled by the global variable STATE.
At line 253 changed 14 lines
Forth, on the other hand, is the original interpretive, in-
teractive, integrated environment. In typical systems, the
editor, assembler, and various debugging utilities are writ-
ten in Forth itself and are kept resident at all times. The
source code for these tools is usually kept on-line, so that
the programmer can tune them to his personal taste. Although
Forth has been implemented in many ways, the "classic" im-
plementation is an unified interpreter and incremental com-
piler based on some startlingly simple concepts and ground
rules. The core of the interpreter/compiler is a loop which
reads blank-delimited tokens from the input stream (which
can be either the keyboard or blocks of text from mass sto-
rage); the disposition of each token is controlled by the
global variable STATE.
When STATE is FALSE, the system is said to be "interpreting." Each token is looked up in the dictionary; if found, the corresponding code is executed. If the token is not found, the interpreter attempts to convert it into a number which is left on the parameter stack; if the conversion is unsuccessful the interpreter issues an error message, clears the stack, and waits for a new command. When STATE is TRUE, the system is "compiling" a new definition. If the token is found in the dictionary, some representation of the word (usually just a pointer) is compiled for later execution. If the token is not found but can be converted to a number, code is generated which will push that value onto the parameter stack when the new definition is executed. In other words, each "compiled" Forth definition is just a list of addresses and literal data, called "threaded code." The addresses refer, directly or indirectly, to executable machine code. When threaded code is "executed," a short routine called the "inner interpreter" walks down the lists of addresses and runs the corresponding machine language procedures. As soon as a definition has been compiled, it can be interpreted "executed interactively by typing its name" or it can be referenced in subsequent definitions. All definitions in a Forth system have equal status, and there is no distinction or artificial barrier between the definitions that constitute the lower layers of the system (including the interpreter/compiler) and those added later as part of an application. An entire Forth program is run by just entering the name of its "highest definition." There are two special classes of words which make the Forth compiler work: 'defining
words' and 'immediate words'. Defining words create a new entry in the dictionary " that is, add a new symbol to the symbol table " and trigger the construction of a new variable, constant, procedure, or other object. The defining word that begins a new procedure " the colon (:) " changes STATE from false to true and thus initiates compilation. The application programmer creates new classes of Forth language objects by defining new defining words, and creates new members of the classes by invoking the new defining words.
At line 268 changed 38 lines
When STATE is FALSE, the system is said to be "interpre-
ting." Each token is looked up in the dictionary; if found,
the corresponding code is executed. If the token is not fo-
und, the interpreter attempts to convert it into a number
which is left on the parameter stack; if the conversion is
unsuccessful the interpreter issues an error message, clears
the stack, and waits for a new command. When STATE is TRUE,
the system is "compiling" a new definition. If the token is
found in the dictionary, some representation of the word
(usually just a pointer) is compiled for later execution. If
the token is not found but can be converted to a number, co-
de is generated which will push that value onto the parame-
ter stack when the new definition is executed. In other
words, each "compiled" Forth definition is just a list of
addresses and literal data, called "threaded code." The ad-
dresses refer, directly or indirectly, to executable machine
code. When threaded code is "executed," a short routine cal-
led the "inner interpreter" walks down the lists of address-
es and runs the corresponding machine language procedures.
As soon as a definition has been compiled, it can be inter-
preted "executed interactively by typing its name" or it can
be referenced in subsequent definitions. All definitions in
a Forth system have equal status, and there is no distincti-
on or artificial barrier between the definitions that con-
stitute the lower layers of the system (including the inter-
preter/compiler) and those added later as part of an appli-
cation. An entire Forth program is run by just entering the
name of its "highest definition." There are two special cla-
sses of words which make the Forth compiler work: 'defining
words' and 'immediate words'. Defining words create a new
entry in the dictionary " that is, add a new symbol to the
symbol table " and trigger the construction of a new variab-
le, constant, procedure, or other object. The defining word
that begins a new procedure " the colon (:) " changes STATE
from false to true and thus initiates compilation. The ap-
plication programmer creates new classes of Forth language
objects by defining new defining words, and creates new mem-
bers of the classes by invoking the new defining words.
Immediate words are so called because they are always executed immediately regardless of the value of STATE. The most important immediate words are the control structure words and the semicolon (;). The control structure words (such as IF or BEGIN) perform syntax checking and then generate appropriate code; for example, IF generates code which tests the value on top of the parameter stack and then performs a conditional branch on the result. The semicolon (;) is the terminator for a definition previously begun with the colon (:), its main action is to change the value of STATE back to FALSE. The application programmer extends the Forth compiler by defining new immediate words.
At line 307 changed 12 lines
Immediate words are so called because they are always execu-
ted immediately regardless of the value of STATE. The most
important immediate words are the control structure words
and the semicolon (;). The control structure words (such as
IF or BEGIN) perform syntax checking and then generate app-
ropriate code; for example, IF generates code which tests
the value on top of the parameter stack and then performs a
conditional branch on the result. The semicolon (;) is the
terminator for a definition previously begun with the colon
(:), its main action is to change the value of STATE back to
FALSE. The application programmer extends the Forth compiler
by defining new immediate words.
!'The Forth Operating System'
At line 320 changed one line
$ 5. 'The Forth Operating System'
For the first ten years of Forth's existence, it was always implemented and sold as a "native" system. That is, not only was it a programming environment, it was the whole environment. Native Forth systems contain their own device drivers and do not run under the control of a host operating system; they take over the entire machine. Moore's goals were speed and compactness at any price, and he was perfectly willing to give up the benefits of hardware independence and file systems in return. Forth interpreter/compilers that ran under host operating systems did not appear until 1979, in the first wave of small software houses that appeared at the time of the FIG-Forth listings. Two of the pioneers in this area were Laboratory Microsystems Inc., which sold a Z-80 Forth for CP/M that used operating system calls for I/O and file management, and Micromotion, which created a similar system for the Apple II. Over time, the advantages of host OS-based Forth interpreter/compilers became obvious, and today about 80% of the Forth programming systems sold fall into this category. So far as I am aware, FORTH Inc. is the
only company still selling native Forth systems as a packaged product, but it now also produces systems that run under MS-DOS, RSX-11, and VAX VMS (among others).
At line 322 changed 22 lines
For the first ten years of Forth's existence, it was always
implemented and sold as a "native" system. That is, not only
was it a programming environment, it was the whole environ-
ment. Native Forth systems contain their own device drivers
and do not run under the control of a host operating system;
they take over the entire machine. Moore's goals were speed
and compactness at any price, and he was perfectly willing
to give up the benefits of hardware independence and file
systems in return. Forth interpreter/compilers that ran un-
der host operating systems did not appear until 1979, in the
first wave of small software houses that appeared at the ti-
me of the FIG-Forth listings. Two of the pioneers in this
area were Laboratory Microsystems Inc., which sold a Z-80
Forth for CP/M that used operating system calls for I/O and
file management, and Micromotion, which created a similar
system for the Apple II. Over time, the advantages of host
OS-based Forth interpreter/compilers became obvious, and to-
day about 80% of the Forth programming systems sold fall in-
to this category. So far as I am aware, FORTH Inc. is the
only company still selling native Forth systems as a packa-
ged product, but it now also produces systems that run under
MS-DOS, RSX-11, and VAX VMS (among others).
In embedded applications, of course, Forth continues to be used in its native incarnation to reduce hardware requirements to a minimum. A special type of Forth compiler, called a target compiler, runs on a full-fledged development system and creates a stand-alone executable image (which can be ROMable). The image is then transferred to the target system by any convenient means " ROM, EPROM, downloading over a serial link, or diskette. Naturally, a target compiler can also be a cross compiler; since the target compiler itself is written in Forth, the CPU upon which the executable image is compiled need not be the same as the CPU upon which the image will be executed.
At line 345 changed 12 lines
In embedded applications, of course, Forth continues to be
used in its native incarnation to reduce hardware require-
ments to a minimum. A special type of Forth compiler, called
a target compiler, runs on a full-fledged development system
and creates a stand-alone executable image (which can be
ROMable). The image is then transferred to the target system
by any convenient means " ROM, EPROM, downloading over a se-
rial link, or diskette. Naturally, a target compiler can al-
so be a cross compiler; since the target compiler itself is
written in Forth, the CPU upon which the executable image is
compiled need not be the same as the CPU upon which the ima-
ge will be executed.
!'The Forth Philosophy'
At line 358 changed 14 lines
$ 6. 'The Forth Philosophy'
If Forth has a credo, it might be summed up as smallness,
simplicity, and speed. Forth programmers traditionally dis-
dain the flashy user interfaces and elaborate error handling
that characterize most integrated environments nowadays.
This attitude has its benefits " for example, a self-contai-
ned interactive Forth system including an editor, assembler,
and even multitasking support can easily be put in an 8 KB
EPROM. It also has its drawbacks " runtime error checking in
a Forth system is virtually absent (unless it happens to co-
me "for free," such as divide-by-zero detection on the Intel
80x86 family). Frequent total system crashes during Forth
program development are taken for granted; indeed, they are
If Forth has a credo, it might be summed up as smallness, simplicity, and speed. Forth programmers traditionally disdain the flashy user interfaces and elaborate error handling that characterize most integrated environments nowadays. This attitude has its benefits " for example, a self-contained interactive Forth system including an editor, assembler, and even multitasking support can easily be put in an 8 KB EPROM. It also has its drawbacks " runtime error checking in a Forth system is virtually absent (unless it happens to come "for free," such as divide-by-zero detection on the Intel 80x86 family). Frequent total system crashes during Forth program development are taken for granted; indeed, they are
At line 374 changed 9 lines
Corollaries to the Forth credo are that intimate access to
the hardware should always be available and portability sho-
uld never get in the way of exploiting a CPU's instruction
set to its fullest. A Forth system without an assembler is
felt by most to be only slightly better than no Forth system
at all. As for portability, you would be amazed at the num-
ber of arguments in the ANSI Forth Technical Committee that
have hinged on whether a particular language feature can be
implemented efficiently on someone's favorite processor.
Corollaries to the Forth credo are that intimate access to the hardware should always be available and portability should never get in the way of exploiting a CPU's instruction set to its fullest. A Forth system without an assembler is felt by most to be only slightly better than no Forth system at all. As for portability, you would be amazed at the number of arguments in the ANSI Forth Technical Committee that have hinged on whether a particular language feature can be implemented efficiently on someone's favorite processor.
At line 384 changed 11 lines
Classic Forth programming style is characterized by many,
many short, relatively simple definitions, bottom-up design,
prototyping, and successive approximations. Forth dogma has
it that an ideal definition should not exceed 2 or 3 lines
and should not contain more than 9 or 10 elements. This en-
sures that individual definitions can be exhaustively tes-
ted; the programmer can simply put parameters on the stack
and exercise the definition interactively through all of its
possible internal paths. It also constrains an individual
definition from becoming too specific, so that it is more
likely to be reusable in the application.
Classic Forth programming style is characterized by many, many short, relatively simple definitions, bottom-up design, prototyping, and successive approximations. Forth dogma has it that an ideal definition should not exceed 2 or 3 lines and should not contain more than 9 or 10 elements. This ensures that individual definitions can be exhaustively tested; the programmer can simply put parameters on the stack and exercise the definition interactively through all of its possible internal paths. It also constrains an individual definition from becoming too specific, so that it is more likely to be reusable in the application.
At line 396 changed 10 lines
The bottom up design of a Forth application derives natural-
ly from the types of problems to which the language is rou-
tinely applied. A typical Forth application involves intima-
te interaction with hardware to acquire data or control a
machine; in many cases, the hardware itself is only poorly
understood or is not yet stable. The Forth words which are
most hardware dependent are thus usually coded first; when
these definitions are proven and the hardware is well under-
stood, the rest of the application is built up by adding la-
yers of increasing sophistication and complexity.
The bottom up design of a Forth application derives naturally from the types of problems to which the language is routinely applied. A typical Forth application involves intimate interaction with hardware to acquire data or control a machine; in many cases, the hardware itself is only poorly understood or is not yet stable. The Forth words which are most hardware dependent are thus usually coded first; when these definitions are proven and the hardware is well understood, the rest of the application is built up by adding layers of increasing sophistication and complexity.
At line 407 changed 9 lines
The emphasis on prototyping and successive approximations
has much the same grounds as the stress on bottom-up design.
In most Forth applications, getting the hardware to do what
you want puts you a long ways toward your goal. After proto-
typing some code that approximates the final form of the ap-
plication, you can simply discard or modify the upper layers
until you get the specific functionality and user interface
that you need; the lower, more hardware dependent levels of
the application rarely require any significant change.
The emphasis on prototyping and successive approximations has much the same grounds as the stress on bottom-up design. In most Forth applications, getting the hardware to do what you want puts you a long ways toward your goal. After prototyping some code that approximates the final form of the application, you can simply discard or modify the upper layers until you get the specific functionality and user interface
that you need; the lower, more hardware dependent levels of the application rarely require any significant change.
At line 417 changed 12 lines
An important advantage of Forth in application design is
that the documented user interface can rely on Forth's own
interpreter, and merely consist of the top layer of defini-
tions. This offers the sophisticated user incredible flexi-
bility, because not only can he use the documented applica-
tion entry points, he can extend the application by putting
building blocks together in new ways, or access lower level
words to test individual hardware components. In environ-
ments with naive users, the Forth compiler and the interpre-
tation of "dangerous" Forth words are disabled, or an appli-
cation-specific, self-contained user interface is written
that does not lean on the Forth interpreter.
An important advantage of Forth in application design is that the documented user interface can rely on Forth's own interpreter, and merely consist of the top layer of definitions. This offers the sophisticated user incredible flexibility, because not only can he use the documented application entry points, he can extend the application by putting building blocks together in new ways, or access lower level words to test individual hardware components. In environments with naive users, the Forth compiler and the interpretation of "dangerous" Forth words are disabled, or an application-specific, self-contained user interface is written that does not lean on the Forth interpreter.
At line 430 changed one line
$ 7. 'Forth's Place in the Universe'
!'Forth's Place in the Universe'
At line 432 changed 13 lines
In 1969 there was exactly one Forth programmer: Charles Moo-
re. When FORTH Inc. was founded in 1973, there were still
probably less than a dozen. In 1979, Moore estimated that
there were about 1000 Forth programmers. In 1988, based on
the number of packaged systems that have been shipped by the
larger vendors and the copies in print of Leo Brodie's 'Sta-
rting Forth' (a popular Forth primer), I'd conjecture that
there are as many as 50,000 serious Forth programmers and
another 25,000-50,000 casual users. This is certainly res-
pectable growth for a grassroots language. On the other
hand, just to keep things in their proper perspective, some-
thing like 1.5 million copies of Turbo Pascal have been sold
to date, never mind C compilers..
In 1969 there was exactly one Forth programmer: Charles Moore. When FORTH Inc. was founded in 1973, there were still probably less than a dozen. In 1979, Moore estimated that there were about 1000 Forth programmers. In 1988, based on the number of packaged systems that have been shipped by the larger vendors and the copies in print of Leo Brodie's 'Starting Forth' (a popular Forth primer), I'd conjecture that there are as many as 50,000 serious Forth programmers and another 25,000-50,000 casual users. This is certainly respectable growth for a grassroots language. On the other hand, just to keep things in their proper perspective, something like 1.5 million copies of Turbo Pascal have been sold
to date, never mind C compilers.
At line 446 changed 9 lines
Looking back over Forth's somewhat checkered career, I can
identify four distinct phases. I think of the first, span-
ning the years 1969 to 1978, as the "secret weapon" era. Du-
ring this time, Forth evolved rapidly as it was used by a
small set of people on highly specialized, demanding pro-
jects. There was no significant user base whose code would
become obsolete when the language was changed, so many new
concepts could be tried out and added to the language whene-
ver they proved generally useful.
Looking back over Forth's somewhat checkered career, I can identify four distinct phases. I think of the first, spanning the years 1969 to 1978, as the "secret weapon" era. During this time, Forth evolved rapidly as it was used by a small set of people on highly specialized, demanding projects. There was no significant user base whose code would become obsolete when the language was changed, so many new concepts could be tried out and added to the language whenever they proved generally useful.
At line 456 changed 13 lines
The second era, 1978 through 1982, marked the transition of
Forth from a little-known proprietary product to a general
purpose programming language. We could call this the "evan-
gelical era" since it was marked by an intense proselytizing
effort by FIG, augmented by Forth's position as the first
inexpensive structured language with graphics, floating po-
int, and its own editor and assembler on the immensely popu-
lar IBM PC (and later on the Macintosh). In retrospect, we
owe the FIG founders a tremendous debt for legitimizing the
language by seeding the "second-sources." Fortunately for us
all, FORTH Inc. had the foresight not to enforce its trade-
mark on the name "Forth;" I trust they have benefited more
than they have suffered by this policy.
The second era, 1978 through 1982, marked the transition of Forth from a little-known proprietary product to a general purpose programming language. We could call this the "evangelical era" since it was marked by an intense proselytizing effort by FIG, augmented by Forth's position as the first inexpensive structured language with graphics, floating point, and its own editor and assembler on the immensely popular IBM PC (and later on the Macintosh). In retrospect, we owe the FIG founders a tremendous debt for legitimizing the language by seeding the "second-sources." Fortunately for us all, FORTH Inc. had the foresight not to enforce its trademark on the name "Forth;" I trust they have benefited more
than they have suffered by this policy.
At line 470 changed 14 lines
The years 1983 through 1986 were a period of Forth retrench-
ment and disillusionment. Most of the cultists, hobbyists,
and nut cases drifted away from Forth as its novelty faded,
and many of the professionals who continued to use Forth
felt frustrated at its lack of penetration of the computer
mainstream. They were convinced that they had a better solu-
tion for many classes of programming problems, but most com-
puter science departments and the larger trade magazines co-
ntinued to ignore Forth's existence. Smaller Forth vendors
were driven out of business by advertising costs, the effort
required to keep up with rapidly changing PC hardware, pub-
lic domain Forths which could be downloaded from bulletin
board systems, and the vendors' tendency to compete among
themselves instead of trying to broaden the market.
The years 1983 through 1986 were a period of Forth retrenchment and disillusionment. Most of the cultists, hobbyists, and nut cases drifted away from Forth as its novelty faded, and many of the professionals who continued to use Forth felt frustrated at its lack of penetration of the computer mainstream. They were convinced that they had a better solution for many classes of programming problems, but most computer science departments and the larger trade magazines continued to ignore Forth's existence. Smaller Forth vendors were driven out of business by advertising costs, the effort required to keep up with rapidly changing PC hardware, public domain Forths which could be downloaded from bulletin board systems, and the vendors' tendency to compete among themselves instead of trying to broaden the market.
At line 485 changed 28 lines
In 1987, we entered the era of Forth maturation and true
standardization. The ANSI Forth Technical Committee (X3J14),
which operated under the auspices of both CBEMA and the IEEE
Computer Society, made slow but steady progress reconciling
the existing Forth dialects, and the after many revisions
the committee's work was finally approved as the American
National Standard for Forth Programming Language in the
Spring of 1994. While an ANSI Forth Standard will not be an
instant cure for all Forth's ills, it should drastically im-
prove portability of both Forth applications and Forth pro-
grammers, and thus make Forth a more viable candidate for
consideration by project planners. Forth development systems
are available for nearly every CPU in existence, and Forth
is consistently the first third-party high level language to
appear on a new CPU architecture, personal computer, or ope-
rating system. Forth continues to enjoy wide use in real ti-
me control and data acquisition applications, and can be fo-
und in the most unexpected places: from the bar-code-reader
"wand" carried by your friendly Federal Express driver, to
the American Airlines baggage control system, to instrumen-
tation for SpaceLab experiments, to a networked monitoring
and control system with some 400 processors and 17,000 sen-
sors at an airport in Saudi Arabia. While I think it likely
that Forth will always remain a somewhat obscure language,
its speed and interactivity coupled with minimal hardware
requirements and ready portability are a unique combination
of assets. In its niche, Forth has no real competition, and
I expect it will be around for a long time to come.
In 1987, we entered the era of Forth maturation and true standardization. The ANSI Forth Technical Committee (X3J14), which operated under the auspices of both CBEMA and the IEEE Computer Society, made slow but steady progress reconciling the existing Forth dialects, and the after many revisions the committee's work was finally approved as the American National Standard for Forth Programming Language in the Spring of 1994. While an ANSI Forth Standard will not be an instant cure for all Forth's ills, it should drastically improve portability of both Forth applications and Forth programmers, and thus make Forth a more viable candidate for consideration by project planners. Forth development systems
are available for nearly every CPU in existence, and Forth is consistently the first third-party high level language to appear on a new CPU architecture, personal computer, or operating system. Forth continues to enjoy wide use in real time control and data acquisition applications, and can be found in the most unexpected places: from the bar-code-reader "wand" carried by your friendly Federal Express driver, to the American Airlines baggage control system, to instrumentation for SpaceLab experiments, to a networked monitoring and control system with some 400 processors and 17,000 sensors at an airport in Saudi Arabia. While I think it likely that Forth will always remain a somewhat obscure language,
its speed and interactivity coupled with minimal hardware requirements and ready portability are a unique combination of assets. In its niche, Forth has no real competition, and I expect it will be around for a long time to come.
At line 514 changed 3 lines
'This section was originally published as "A Forth Apologia"
in 'Programmer's Journal', Volume 6, Number 6, November/De-
cember 1988, page 56.'
'This section was originally published as "A Forth Apologia" in 'Programmer's Journal', Volume 6, Number 6, November/December 1988, page 56.'
This page (revision-4) was last changed on 03-Feb-2023 15:21 by Carsten Strotmann  Top