Comment by RodgerTheGreat
5 years ago
There has never been one Forth. In a world with N Forth programmers, one can expect roughly N implementations of Forth. Perhaps closer to 2*N. An ANS spec exists, but most Forth programmers would say it misses the point.
Forth is a collection of ideas and philosophies toward programming as much as it is a language. Two stacks and a dictionary. Threaded code (direct, indirect, token, subroutine, etc...). Collapsed abstractions. No sealed black boxes. Tight factoring.
C has changed. Forth is everchanging.
Well, shit... I've been a lil frustrated by a lack of a clear resource and consequentially haven't gotten far on a couple half-hearted attempts to learn it. I can just make it up myself? A little late in the weekend for a new project, but I'm suddenly interested again.
This is a slightly off topic question for you, do you think the attributes you named are required for having a “Forth” or are they just the most common implementation characteristics? My current pet language project certainly looks Forth-like, with different semantics and a modal dependent type system, but is not threaded nor does it have the traditional stacks and dictionary. I don’t know if I’d call it a Forth, but maybe it is?
"The dictionary" can be implemented in many ways; simple or clever, namespaced or not. A language without any form of local or global name binding would presumably need quotations ala Joy/Factor, which means your stacks probably have to store objects rather than raw numbers. This tips the scale in the direction of a higher-level language.
The stacks are likewise a description of semantics rather than implementation. Some Forths keep the top few stack elements in registers to reduce overhead. If the return stack isn't user-accessible (r> >r etc.) then, again, you're straying closer to a higher-level functional language than a Forth.
There are many kinds of threaded code. For example, subroutine-threaded code uses native subroutine call instructions in word bodies and does away with the inner interpreter. Threaded code is a natural consequence of disentangling conventional "activation records" into two stacks which grow and shrink independently. You could have a Forth without threaded code, I suppose.
Some Forths attempt to "seal off" or otherwise obscure some parts of their own internal workings from "user programs". This is more common among dialects which try to adhere to ANS specs, like GForth. This isn't a total anathema to Forthiness, but it tends to introduce additional complexity. If a word is useful for implementing a forth kernel, why couldn't it be useful in implementing other functionality, too?
If you're building something higher-level which vaguely resembles Forth, it's probably better to describe it as a concatenative language. A dependent type system doesn't sound very Forthy, imo.
I don’t think you’re wrong in your assessment. But just for fun I will point out that I probably assumed a bit to far when I stated no dictionary, there is a name binding mechanisms for ‘words’, but I have a quote form as well. Also, while I would say the language is functional, it is also intended to be low level, ideally, the base of the language is a dependently typed pseudo-assembly language, but the modal type system and homoiconic syntax enable building words that are semi-macros. It is, at this point, basically my attempt to blend Forth’s philosophical leanings with category/type theory. But thanks for the reply, outside perspectives are always great for me to hear.
"You could have a Forth without threaded code, I suppose."
VFX Forth from MPE UK is a native code generator. It evaluates source code and emits inline code or calls depending what you tell the compiler to do. It can expand everything to inline if you tell it but your code would get much bigger.
This is the state of the art for Forth compilers today.
Homemade systems and older systems use threaded code.
I have no affiliation with MPE.
There has been OpenFirmware.