Forth/Core ideas of FORTH

Before giving details of language specification, let us take a moment to point out several aspects of the flavour of FORTH so they can be kept in mind during the subsequent pages.

• Many requirements of traditional programming environments are actually unnecessary and based on historical baggage.
• Careful specification of system elements causes them to become much smaller in code size. This process feeds on itself.
• One pass compilation and a style that discourages references to things that haven't yet been defined provides subtle pressure that eliminates enormous numbers of programming bugs based on Russell's paradox type code (circular definitions).
• Factoring is encouraged because the overhead to define and call a subroutine is reduced due to implicit parameter passing on the Data stack. This encourages definition of a subroutine for each sequence of operations that is used in multiple places. This shrinks the size of the code and encourages good coding practice of implementing each algorithmic component in one centralized and maintainable subroutine.
• Structured programming conditionals in best mathematical computer science style are used. Programmers are led to follow the mathematical requirement of having only one entry point and only one exit point for code snippets.
• The programmer should be able to make the code read as they want it to look like, eliminating a level of confusion due to required language syntax. It should be possible to have the meaning of code stand out from skimming it.
• The "Tower of Babel" issue lurking in computer languages is made explicit and democratized. You, not the language designer, get to create a dictionary and name the words in it. It is your dictionary. If you want to share vocabularies with other people, well then you all have to agree what to name the word for a particular function. If you don't like the name given, you can define a new word with the name you like that points to the original definition.
• If there is a capacity already built into the software somewhere, it should always be available to be called by the programmer. This the Forth axiom: "Don't hide your tools". This is unlike most other systems, where you can see many applications already contain code for doing a programming task you may wish to use, but this code and its constituents are not callable or available to you if you sit down to write a program.
• Demystification of the concept of "the compiler". The compiler and its required functionality become a few words in the dictionary whose behavior can be mastered by intermediate students. They can be used, extended and modified.
  • Even the concept of the compiler is simplified in the Forth understanding.
    • The comma operator "compiles" an integer into the next available memory location.
    • The C, operator compiles a character (or byte) into memory
    • The Forth Assembler word MOV is a "compiler" for only one machine instruction
• Forth specifies its language rules, by which you and the computer communicate, that are simple and consistent with an articulatable philosophy behind them. Without the blizzard of special characters and complicated precedence rules, both communicants benefit. The programmer feels they are working in harmony with a few KB of understandable compiler code instead of fighting megabytes of coded exceptions and special cases. The compiler writer has a well defined set of rules that can be exactly and correctly implemented. Moments of ambiguity between compiler bugs and language manual vagueness are therefore minimized.