The colon definition grammar.
The post-fix expression grammar.
Two stacks.
On-line dictionary (symbol table) at development time, and, unless explicitly removed, at run-time.
The ability to blend run-time with compile-time at development time.
But this is way too loose. It leaves out all sorts of implementation details that non-trivial applications depend on.
Comparing it to the programming language C, it's like saying that, not just all K&R C compilers are included as C, but all the different versions of Small C and Tiny C. (And maybe even Objective C, Javascript, Java, Ruby, PHP, and a number of other languages that borrow heavily from C syntax and grammar?)
The solution?
fig-Forth is one group of dialects that have a lot in common. We could define and develop a standard fig-Forth.
I've transcribed the 6800 fig-Forth model and optimized it for the 6801. In addition to some I/O bugs, there are enough differences from the 6502 model to cause problems for non-trivial applications.
I have a near-fig-Forth I call BIF-6809 (and a non-functional one I call BIF-C). They use a binary tree symbol table, and that alters the language enough to make it unreasonable not to give them separate names. (Double negative intentional. Not just reasonable to have separate names, but unreasonable not to.)
Forth77 and Forth83 are separate languages, and should be treated as such. And they should be referred to by their complete names.
SwiftForth's language should be referred to as SwiftForth.
ANSI Forth should be renamed. Call it CommitteeForth or something.
The name Forth, unadorned, should be reserved to whatever Charles H. Moore (the original author of Forth) wants to call Forth.
(I should note that Moore himself calls his own dialect ColorForth. He's leading out, here.)
We need to make the nomenclature a part of the dictionary/symbol table. A word called version should bring up a version number, sure.
We need a word that returns (without printing it to the terminal) a string containing the name of the language/dialect. Maybe even one word for the language family name and one for the dialect. That would give us a base point, after which it would become possible to check what kind of glue needs to be brought it, to make a particular source code compilable with a particular compiler.
After some consideration, I'll suggest the following four new words:
* language ( --- adr )
Returns a string containing the language name, "Forth". (This would allow distinction from derived but different languages.)
* dialect ( --- adr )
Returns a string containing a dialect name, "fig-Forth", "Forth77", "Forth83", "SwiftForth", "gforth", "BIF-6809", etc.
* sub-dialect ( --- adr )
Returns a string containing a modifier of the dialect name.
* target-cpu ( --- adr )
Returns a string containing the CPU targeted, such as "6502", "6801", "Z80", etc.
In addition,
* version ( --- ud )
Should return an unsigned double integer in which the first byte contains the major version number, the second byte the minor, and the third and fourth contain a sequencing number within the minor version.
To further aid tuning source to the host language, run-time, CPU, etc., dialects which adopt this practice should also adapt the practice of defining words that describe such things as cell width, sign representation, defined boolean constant to set a logical true, etc. We could take some inspiration from C's (original, sparse) limits.h include file for this, but it should not duplicate the contents of limits.h.
