!!Introduction to FORTH

(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)

Revised 10/07/95

[{TableOfContents }]

! 'Introduction to the Forth Programming Language'

"I have yet to see a decent  piece  of  software  written in
Forth. Let's face it. Forth stinks." --- John Dvorak, provocateur and columnist, InfoWorld, October 29, 1984.

"Forth is the first language which has  been  honed  against
the rock of experience before being cast  into  bronze." --- Charles Moore, inventor of Forth.

"Only brain-damaged programmers use  Forth." --- Alan Holub, ex-C columnist, Dr. Dobb's Journal.

"Forth is like the T'ao;  it  is a Way, and is realized when followed. Its  fragility is  its strength; its simplicity is its   direction."   ---  Michael  Ham,  ex-Forth  columnist, Dr. Dobb's Journal.

As this charming collection of aphorisms demonstrates, Forth
is not a programming language that provokes lukewarm, wishy-washy sentiments.  With  rare exceptions,  Forth programmers
are passionately enthusiastic about  the language,  and will
bend  your  ear  for hours about how it changed their lives.
Most other programmers view it with the sort of distaste mingled with wary  respect that is ordinarily reserved for Ma-
fia chieftains and the authors of software viruses.  How did
Forth  acquire this reputation as the  "bad boy" of programming languages? Some of it is undoubtedly based  on  hearsay
from pundits like Mr. Dvorak and  Mr.  Pournelle, on Rolling
Stone  interviews  with  scruffy-looking Northern California
hackers, on well-meaning but misguided  promotional  efforts
by Forth groupies, and on the chaotic appearing, uncommented
Forth source code published in trade magazines (when any code is published at all). Some of it stems  from  sensational
(and sensationalized) disasters like EasyWriter and Valdocs,
both of which happened to be written in Forth. In  addition,
there is always the snobbery factor and the Not-Invented-Here syndrome; "if they didn't teach me about it  at  Stanford
in Computing Science 1A, it can't possibly be any good."

But the largest ingredient in Forth's roguish  renown  seems
to be an appalling ignorance of Forth's true nature and features in the general programming community. For example, Microsoft  recently  billed  the  use of threaded code in its QuickBasic product as a technological  breakthrough,  while exactly  the  same technique has been used in Forth systems for  nearly twenty years. Reviewers marvel over the new integrated  programming  environments from Borland and Microsoft,  oblivious to the fact that Forth was providing integrated environments with  an interpreter, compiler, editor, and  assembler  in less than 16 KB of RAM for nearly 15 years before Turbo Pascal. Many of the authoritative reference works on programming languages don't  mention  Forth  at all, and C programmers (of all people) are often heard criticizing Forth's "write-only" source code.

I  find the contemptuous attitude toward Forth that is common among C programmers especially disconcerting, because the two languages are virtually contemporary, were designed with many  of the same objectives, and require much the same sort of approach when solving a particular  programming  problem. This  impression of similarity is supported, in my experience, by  the ease with which Forth programs can be translated to C and vice versa. Applications written in Forth and C are also prone  to  many of the same sorts of bugs, because both languages are tightly coupled to the hardware and  allow you to mangle pointers and data in any way you  like. Forth  is, like  every  other programming language,  simply a tool with
particular strengths  and weaknesses that reflect the original concerns of its designer. In  the  appropriate settings, Forth is without peer, just as  Fortran  is  inarguably  the best tool for crunching numbers, LISP for crunching symbols, and Prolog for crunching rules. While it is not my intention to teach Forth programming in this section, I would like  to place some of the claims and counterclaims about Forth  in a more reasonable perspective.

!'Some Forth History'

Although Forth and C were conceived at almost the same time, their  origins were vastly  different. C, with its fraternal twin UNIX (TM), was born in one of the very bastions of computer science academia "Bell Labs" and its author,  Dennis Ritchie, has ascended in the ensuing years to near-sainthood status. For a  long time quality C compilers were only available in the UNIX environment, and while UNIX was fiendishly expensive to license for commercial  users,  AT  practically gave it away to universities. Thus, an entire generation  of computer science students and faculty were weaned and raised on UNIX and C and made it their true faith. 

In contrast, Forth is literally a  grassroots  language;  it has made its way in the world strictly  on  its own  merits, lacking  endorsements from the learned professors or distinguished looking  textbooks from Addison-Wesley  or Springer-Verlag.  Forth  was  invented  by Charles Moore, a freelance programmer  who had worked  on control  and data acquisition applications  in  environments ranging from a carpet factory to the Stanford Linear Accelerator Center. Moore was familiar with many programming languages, including assembly, Fortran,  COBOL,  PL/1, and APL, but felt that none of them met his needs  well.  He experimented extensively with interpreters  in the  early 1960s, eventually hitting on the idea of using a stack to pass parameters and results between the interpreted commands.

Moore recounts that his first interpreter which was recognizably Forth  was  written in Fortran on an IBM 1130 while he was working at a carpet manufacturer (Mohasco Industries) in 1968. He subsequently cross-compiled it to a Borroughs 5500, which  was  a CPU with push-down stacks that supported Forth much more gracefully, and then to a Univac 1108. Shortly afterward, Moore went to work for the National Radio Astronomy Observatory (NRAO) and ported Forth to a Honeywell 316.  The language  had been evolving rapidly during these ports and a compiler was  added  in  the Honeywell version, resulting in the first Forth system in the modern sense and making it possible (eventually) to rewrite Forth in itself.

NRAO  didn't appreciate the implications of Forth and, after some preliminary investigation into its patentability, released  all  rights  to  the language to Moore. Astronomers at Kitt Peak Observatory were soon using Forth on several Varian minicomputers for telescope control and data acquisition.

In 1973,  Moore, Elizabeth Rather (the second Forth programmer), and several  others formed FORTH Inc. to sell Forth as a  commercial product, originally called miniFORTH and later polyFORTH (TM). The language was soon running on several additional processors; the most important of these was the DEC PDP-11, which remains a mainstay of the FORTH Inc. user base today.

For  the  next  five years, Forth the language and Forth the proprietary  product  of  FORTH  Inc. were one and the same. There were no other commercial vendors of Forth systems, and in  fact  the name Forth  itself  was  trademarked. Although FORTH Inc. moved polyFORTH onto a broad variety of microprocessors as they became available, it  maintained  prices  at mainframe levels. Except for a few scattered systems (descended from Moore's original NRAO implementation)  in  use  at university  astronomy departments, Forth was essentially inaccessable to  casual or  tentative  users. In 1978, a small band of Forth  enthusiasts  formed  the Forth Interest Group (FIG) in San  Carlos,  California.  They  assembled  a  team which,  over a  nine month period, designed a simple, transportable  implementation of the Forth language, and then implemented it on the Intel 8080, DEC PDP-11, TI  9900,  6502, PACE,  and  Motorola  6800. This implementation, called FIG-Forth, was released into the public domain; Xeroxed listings were  sold  for  a  nominal  fee ($10) and were disseminated worldwide in a matter of months. Some of the  purchasers  of
the  original  listings performed further ports to the Intel 8086, the  Nova, the  RCA 1802, the Motorola 68000 and 6809, the Alpha Micro, the VAX, and even the Data General Eclipse, which were also placed in the public domain.

Although  the  FIG-Forth implementations were slow and crude by  todays  standards, they were perfectly suited to the times. In those days, RAM was dear, 5.25" floppy disks held 60-70 KB, and cassette tape or even paper tape was still a common  mass storage device. A high-level interactive language with minimal memory requirements,  available  with  complete source code, was the answer to many microcomputer experimenters' prayers.  The FIG-Forth movement was given an additional impetus  by the August 1980 issue of BYTE, which was devoted  almost  entirely  to Forth articles and exposed Forth concepts  to  the  general  microcomputing community for the first time. The FIG-Forth listings also provided a launching
pad for dozens of would-be Forth entrepeneurs. Since the listings reduced the ante  for becoming a programming language vendor practically to  zero, Forth software houses sprang up by the dozens, several for each microcomputer that was popular  at the time. Although most of these Forth-vendor-wannabes did not survive, the influx of new blood  brought  about rapid improvements  in Forth development tools. For example, prior to 1979, stand-alone  Forth  systems with line editors and integer  arithmetic  only  were the rule. By 1981, Forth systems  that  ran as well-behaved tasks under a host operating system, used normal files for program and data storage, and supported  floating  point arithmetic and visual editors
were  readily available from  the  software houses which had gotten their start with FIG-Forth.

With the success of the FIG-Forth implementations under their  belts,  the  founders of the Forth Interest Group looked for new  fish to fry. The Forth Standards Team, a self-appointed  spin-off from FIG, commenced deliberations to "improve" the language and issued the Forth-79 Standard in October 1980.  Forth-79 was incompatible with both FIG-Forth and polyFORTH,  failed  to supplant either, and consequently had a most regrettable effect on Forth source code portability and the publishing of Forth textbooks and articles.  Although it may seem difficult to believe, the Forth Standards Team proceeded to splinter the Forth community even further with the release of the Forth-83 Standard, which was (again) incompatible with all existing Forth dialects including Forth-79.

Forth-83, with all its problems, did have two highly desirable  side-effects. First,  the  public domain FIG-Forth listings, which by 1983 were severely dated, were replaced virtually overnight by a popular public  domain  implementation of Forth-83 called F83, written by Henry Laxen  and  Michael Perry. F83 could recompile itself (FIG-Forth required an external assembler),  had multitasking capabilities, ran under a host operating system, and generally represented a quantum jump  in  power and  sophistication over FIG-Forth. (F83 was eventually  superceded  by  a  public domain multi-segmented Forth  written by Tom Zimmer.) Second, rumblings about reactivation  of  the Forth  Standards Team in 1987 caused major
Forth vendors and users to band together and launch an  ANSI standardization effort.

In  the  last few years, the Forth language vendors have undergone a severe shake-out, and  only  a  half-dozen  remain with  solid  product lines and significant user bases. (Judging by  the number of  companies who are managing to make a living in the  much larger  C marketplace, this may still be too  many for the long haul.) FORTH Inc., with Elizabeth Rather as  president, is clearly  the flagship of the vendors; its  revenues  and staff exceed those of all the other Forth software houses taken together. Only FORTH Inc. has achieved the critical mass to offer a complete range of services: consulting,  custom  applications  programming, education, and tools;  the  other vendors appear to subsist almost entirely on sales of packaged development systems.

While the pace of change has slowed in Forth programming tools, some exciting things have been happening on the hardware  front.  Several  CPUs have been designed  and built with Forth  instruction sets,  including Charles Moore's Novix NC 4016, Alan  Winfield's MF1600, and Phil Koopman's WISC (Writable Instruction  Set Computer)  CPU/32. The performance of these machines  is quite astonishing. For example, the Novix processor  can crank  out  well over 4 MIPS, yet requires so little  power and so few support chips that it can easily be built into a handheld computer.

!'Some Forth Terminology'

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.

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.

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.

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.

!'The Forth Language'

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
formats out of existing data types with 'struct'.

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
of mastering a Forth system quite forbidding.

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.

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!

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:
1 2 +
whereas in C, which uses infix syntax, you would code:
1 + 2
and in LISP, which employs prefix syntax:
+ 1 2
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.

!'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.

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.

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.

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. 

!'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).

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.

!'The Forth Philosophy'

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

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.

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. 

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.

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.

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.

!'Forth's Place in the Universe'

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.

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.

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. 

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.

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.

'This section was originally published as "A Forth Apologia" in  'Programmer's Journal', Volume 6, Number 6, November/December 1988, page 56.'