DMD 1.005 release

[Kevin Bealer]

Charles D Hixson wrote:
...
> Forth is very similar to LISP, only with a simpler grammar. I.e., the 
> grammar is simple serial execution, with  certain words (those marked 
> immediate) able to manipulate the input stream to determine what will be 
> the next in order.

I think the comparison to LISP is a good way to think about forth:

1. Write a lisp program, but put the function name after its arguments
    for every expression.  This will be hard to read but by following
    the parenthesis you can just barely tell what is happening.

2. Remove all the parenthesis.

At least 90% of the time, if you remove a symbol from a valid forth 
program, you get a valid (but incorrect) forth program -- there is 
almost zero redundancy in the language so errors are almost never 
detectable at compile time, which means you should write short clear 
functions.

But the central feature of FORTH is that the compiler and runtime can be 
made mind-bogglingly small.  I think the run time speed for a naive 
interpretation is probably somewhere between C and interpreted bytecode.

 From this page about tiny4th: http://www.seanet.com/~karllunt/tiny4th

"The run-time engine takes up less than 1K of code space and the p-codes 
are so dense that you can get a lot of robot functionality in just 2K."

Of course, that's a compiler; an interactive language environment can be 
used for prototyping (like with lisp) and that will run a bit bigger.

Kevin