[FoRK] Superhuman feats of programming expression

[Andy Armstrong]

On 3 Feb 2008, at 18:25, Stephen D. Williams wrote:
> Have you considered Forth?  (Or it's less bare metal cousin,  
> Postscript?)

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  
syntax.

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  
language.

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