Comment by CameronNemo
5 years ago
Perhaps Forth has changed less than C in that time. The C of 48 years ago can look quite different from modern C.
5 years ago
Perhaps Forth has changed less than C in that time. The C of 48 years ago can look quite different from modern C.
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.
2 replies →
There has been OpenFirmware.
Not really. Function definitions look different, and we can declare variables in the middle of function bodies, but those are surface-level changes. The language itself hasn't changed appreciably.