Lambda the Ultimate

inactiveTopic Chuck Moore holds Forth
started 9/16/2001; 8:00:47 PM - last post 9/21/2001; 1:05:52 AM
Chris Rathman - Chuck Moore holds Forth  blueArrow
9/16/2001; 8:00:47 PM (reads: 1169, responses: 3)
Chuck Moore holds Forth
Chuck Moore, the inventor of Forth and colorForth, discusses the language as well as programming languages in general. He definitely comes down on the side of dynamic and flexible languages, as opposed to the more formal systems like Lambda Calculus based functional languages. Whether you agree with his positions or not, he's always a good read.

Speaking of Forth detractors, there's a couple of articles over at Embedded Systems called I hate Forth and Forth Followup. Mostly of the language war variety, but it does showcase the point of disagreement about flexibility in implementation versus the rigorousness of design. Also interesting anecdotal numbers about language usage in the embedded space (my own take is that C is still the number one choice with C++, Ada lagging behind, and Java carving out some significant niches).
Posted to general by Chris Rathman on 9/16/01; 8:05:33 PM

Michael Christopher Vanier - Re: Chuck Moore holds Forth  blueArrow
9/16/2001; 10:03:01 PM (reads: 1202, responses: 0)
Well, lisp is a mostly functional language more-or-less based on lambda calculus, and scheme is explicitly based on lambda calculus. Both of these languages are extremely flexible and dynamic, so I find your comment difficult to understand. Forth is flexible from the standpoint of how easy it is to hack its own compiler, but that's flexibility of a quite different kind.

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.

jon fernquest - Re: Chuck Moore holds Forth  blueArrow
9/20/2001; 5:41:10 AM (reads: 1147, responses: 0)
Has anyone implemented a forth interpreter in Scheme? Or Scheme on top of Forth?

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"):

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?


Jon Fernquest

Michael Christopher Vanier - Re: Chuck Moore holds Forth  blueArrow
9/21/2001; 1:05:52 AM (reads: 1121, responses: 0)
I think you could implement something Forth-like on top of Scheme, but since Scheme doesn't give direct access to machine addresses and Forth normally does, it wouldn't be a real Forth. I suppose you could define a simulated memory region with simulated address-of operators etc. in scheme and build a Forth on top of that, but it would be pretty slow.

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 :-)