Forth, LISP, etc...

[Tom Novelli]

Well, I started writing this message a few weeks ago, but I forgot to
finish it...

On Thu, 10 Dec 1998 19:06:53 -0800, David Jeske wrote:
> There are certainly good properties in both Forth and LISP. Can
> someone refresh us or point us to a description of Forth's strengths
> and limitations for tunes?

Allright, I'll try to sum it up: Forth uses two stacks instead of one.
There's the "return stack" for CALL/RET's, and the "data stack" for
manipulating things. Programs are written in postfix notation (Reverse
Polish Notation), and statements consist of only numbers (which are
pushed on the stack) and commands (which manipulate the stack). The
Review project has links to all the Forth sites I know of.

Pros: Simple syntax. Easy to implement a compiler. Fast compilation.
Easy to port. Interactive. Reflective (more or less). Extensible.

Cons: No module system. No explicit data typing. Confusing (for anyone
accustomed to other languages). Only standardized at a low level.

> If we agree with the presumption to base work on Forth, why wouldn't
> we just write our stuff under Forth for Linux or any other existing
> OS?

Forth would be especially useful in writing the low-level parts of the
standalone version of Tunes. It beats the hell out of assembly language,
which should only be used when optimal performance is needed. Now, if we
want a version of Tunes that doesn't use ANY assembly, Forth would make
a good "portable assembler". There are even Forth microprocessors whose
assembly language is a subset of Forth.

> We can already do all these things with existing systems.
>
> One of the major goals of tunes (IMO) is to be able to figure out a
> programming model where we can programs things like you mention _once_
> and truly be able to reuse them wherever we need to, and to be able to
> abstract out things like the 'symbolic language you use to enter a
> program'.

That's a good point. I'm not convinced it's possible to make Tunes
totally language-independent, but we can sure as hell try. The new HLL
should support multiple syntaxes (algebraic, RPN, LISP, syntax tree) in
the same program. Also, it's easy (if not efficient) to interface with
C, Scheme, CORBA, etc. A C interface would be great for using drivers
from other systems, GGI, OSKIT, etc...

I've been working on this a little. I started by comparing three major
programming paradigms, represented by C, Forth, and LISP. They all
represent syntax trees. For example:

C: x = (2 + y) * (7 - a)
(Algebraic notation is useful)

APL-like?: (2 + y) * (7 - a) --> x   
(The arrow is the important thing. My TI-85 calculator uses this
syntax.)

Forth: 2 y +  7 a -  *  x !   
(Note: x ! stores the result in x)

LISP: (setq x (* (+ 2 y) (- 7 a)))
(Ugh. Of course, math isn't LISP's strong point.)

Syntax tree: Look at http://members.xoom.com/unios/vde.html
That's the basic idea, except in my example, the nodes would be numbers
and operators, not pictures. Anyway, you take 2 and y, and send them to
+. At the same time (if you have 2 processors), you send 7 and a to -.
Then you send the results of + and - to *, and send that result to the
variable x for storage.

While I currently favor Forth, I'd use all of the above at the same
time. Fare mentioned how the HP-48 is an RPN calculator, but it's got an
"algebraic expression evaluator" so you can use normal notation too.
That's a step in the right direction.

This "arrow" thing could be useful for functional programming, as a way
of visualizing complex programs/equations. When I'm doing math, I prefer
to use arrows instead of variables to show how I tied different
equations together. It's just easier. :)

Well, that's enough for now.

--
Tom Novelli <tcn@clarityconnect.com>
http://www.clarityconnect.com/webpages5/tcn