Lambda the Ultimate

I used to really like Forth, and still do to some extent. However, I've always found it incredibly hard to get work done in it, not to mention the fact that Forth's efficiency is abysmal unless the Forth system runs the entire OS (as Chuck advocates). Forth is really IMO an extensible assembly language and should be thought of that way. Chuck Moore just doesn't seem to get why people (even people who aren't afraid of postfix notation) find Forth difficult to use. He always says they aren't factoring enough, which may be true, but when you have to write several small functions to compute a simple arithmetic expression (for instance, the solution to the quadratic formula) it seems like overkill. Much of this has to do with the over-reliance on stack manipulation operators, which makes code pretty much incomprehensible. Many (most?) Forths have some kind of support for local variables as well (e.g. Gforth), but their use is frowned upon in the Forth community.

To me, Forth is an example of a violation of Einstein's dictum: "Make it as simple as possible, but no simpler". In my opinion, Forth tries to make things too simple, and suffers as a result. It's still a very interesting language, though.

I associate "Forth" with a conceptually simple elegant stack-based virtual machine. A sort of competitor or alternative to the Java Virtual Machine.

I find this paragraph particularly appealing:

>There is no better environment for figuring out hardware, though.
>When we're confronted with a peripheral with 50 programmable registers,
> most probably poorly documented, we've got no choice but to sit down
>and play with the device. Though it's possible to use any debugger to
> issue specific port input/output commands, Forth shines as we can
> try something simple and then enshrine it as a "word", which gets
>reused as we learn more about the device.

I think it's a given that most things in the world of computers are not well documented and you have to poke around and find out how they work for yourself. You can't do this with the Java virtual machine. If Forth provides a systematic way to do this , it must be a winner. (Can you use Forth to figure out how a device works and then write a device driver for it ?)

Can other languages be built on top of Forth using it as an abstract machine? (like the stack based implementation of Scheme in Kent Dybvig's thesis "Three Implementation Models of Scheme"):

http://www.cs.indiana.edu/~dyb/pubs.html

The articles seemed to implie that Forth was somehow incompatible with formal methods. Why? Forth people get their hands dirty with real hardware and interfacing problems?

Cheers,

Jon Fernquest

There are many differences between the JVM and Forth. One is that the JVM uses a conventional frame-based stack where each stack entry contains all the information needed for that function invocation (e.g. the local variables, the return address, constants, etc.). Forth, on the other hand, has two stacks: the "parameter stack" which has data that the current function (and all other functions) is/are manipulating, and the "return stack" which keeps track of function return addresses. Other stack-based languages like Postscript can have even more stacks (Postscript also has a dictionary stack for local variables and a graphics state stack). Also, in the JVM I don't believe (don't quote me on this) that the user has explicit control over how the stack is managed, whereas in Forth you can (for instance) play games with the return stack to implement your own control words. Philosophically, Forth's VM was designed to be extensible and Java's was not.

As for the notion of using Forth with formal methods, it's important to recognize that Forth is normally intended to directly manipulate machine addresse much like C does. Languages that do not provide any insulation between the programmer and the machine, like Forth and C, tend to make formal analysis difficult, for a lot of complicated reasons I only partially understand :-)