[FoRK] Superhuman feats of programming expression
<andy at hexten.net> on
Sun Feb 3 10:49:51 PST 2008
On 3 Feb 2008, at 18:25, Stephen D. Williams wrote:
> Have you considered Forth? (Or it's less bare metal cousin,
Forth is a magical thing but not really practical for the kinds of
problem people want to solve these days. Unless they're controlling a
telescope of course :)
It /is/ worth studying if you're interested in a languages. The Forth
core has no parser to speak of (it chunks input into words and that's
it). It's possible to bootstrap a perfectly usable Forth with only a
few hundred bytes of non-Forth - often assembler. Most of the
'languageness' (control structures, word definition, non-numeric
constant parsing, just about everything else) is implemented in Forth
itself - a trick made possible by the fact that the Forth machine has
two states, compiling and running, and every word conceptually has a
compile-time behaviour and a run-time behaviour. For most words the
compile time behaviour is just "compile a call to myself into the word
we're currently defining" but that's just the default. A simple
example. Here's how you print a string:
." Hello FoRKers"
and here's how you compile a word that does the same thing
: hifork ." Hello FoRKers" ;
The string parsing is done by a word called '."'. That's why there's a
space at the start of the string; it's actually the space after '."'.
At runtime ." parses and displays the string. At compile time ."
parses the string and compiles it into the current word along a call
to another word that will print it out. Forth itself doesn't need to
know anything about string constants. We could just as easily embed an
XML parser into a word called <?xml> and have seamless XML literal
So fundamentally compiling and running are just two arbitrary states.
Everything else flows from that.
Forth culture has it that you're not a Forth hacker until you've
implemented your own Forth. It's not that much of a hurdle. I've done
it (years ago on a 6502) and I'm still nowhere near fluent in the
Not, I think, much practical use but a great wedge to drive into your
preconceptions about what a language has to be.
> Of course, the problem with Forth is that it wasn't lazy evaluated
> or without side effects, so you had a nice program structure but
> without real optimization, so large programs tended to be slower
> than they should have. Epson had a whole office application suite,
> and possibly the OS also, written in Forth, running on floppies. We
> sold them in 1983. My attorney had one. Amber screen. Fairly
> nice, but not fast.
QX10 I think. See also: Canon Cat, Jupiter Ace.
Andy Armstrong, Hexten
More information about the FoRK