Forth, LISP, etc...

[William Tanksley]

On Thu, 31 Dec 1998, Tom Novelli wrote:

>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.
[...]

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

Don't forget Simple.  Anyone can write a Forth environment.  That's a pro
:).

Forth is also interesting in its different model of the relation between
functions and data.  I'm sure you've all read Henry Baker's paper on
"Linear Logic", regarding how Forth sort of models a mathematically
precise memory management system.  It goes deeper than that, though.

In most languages, "data" is something that you pick up and move around
into "functions", which are black boxes that accept data in at one end and
produce a result out at the other end.  Data is passive, and the functions
act on it.  In addition, the functions are usually pictured as black boxes
that you probably wouldn't want to take apart or otherwise fiddle with.
(Forgive my generalization to "most languages" here.)

There are many examples of language support for this model of computation.
Storage variables, for example, are things which contain (or appear to
contain) an entire data item, thus implying that the function using the
variable contains the data item (at least temporarily).

In contrast, I see a different model.  Data is pictured in my model as
being part of a flowing whole.  You can't simply pick up the data and drop
it into a black box without seperating it from the flow; therefore,
functions can't be pictured as giant black boxes.  Instead, functions are
tools, usually hand tools.  You don't pick up the data and bring it to a
machine; you pick up the tool and hold it up to the data, where it does
its work.

I don't claim that this is a superior model, only that it's the model
which Forth uses.

Does it fit with Tunes?  I like how this model gives an impetus to view
functions as being simple and relatively transparent (encouraging user
modification at least on a high level), while data is viewed as being
complex and black-boxed (in fact, it is).

Ahem.  Anyhow.  :-).  I'm just now developing these ideas -- am I making
any sense?  Stop me before I confuse anyone ;-).

>Cons: No module system.

A HORRIBLE negative.  It's hard to see it becoming a Tunes-quality
language without this -- we have to be able to load someone else's toolkit
without having them accidentally modifying ours.

I seem to recall that a solution to this was reached with Open Firmware
(by Sun, later standardized by ISO).

>No explicit data typing.

This isn't that big of a negative -- nothing a solid ML-style type
inferencer wouldn't handle given a few days of computation ;-).  Okay,
you'd probably want to modify the language as well.  But I think it would
be an improvement, and I don't see it causing any disruptions to Forth in
general.

>Confusing (for anyone accustomed to other languages).

Not even a negative.  Not really true.  Sure, the code is hard to read if
you're expecting something else -- but it's _easy_ to teach, and once it's
learned most of it is straightforward.

>Only standardized at a low level.

I'm not sure I understand you.  The ANSI standard is quite high level,
containing word names and actions.  The old standards defined Forth in
termms of a virtual machine; the new one explicitly avoids that.

[... subject change...]

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

This is sometimes known as "Fortran notation", since Fortran was the first
sucessful language to try to imitate a mathematical formula.  Most
computet scientists spend years learning this, and the rest of their lives
claiming that it's the only reasonable way while desperately trying to
solve bugs resulting from the fact that computer programs aren't
mathematical formulas, even in functional languages.

I do agree that it's very useful, though.  I like having INTRAN around, a
little tool for Forth which simply does an in-place translation of integer
formulas (for example, i" a=();b=();c=(); (b**2 + sqrt(-b + 2*a*c))/2/a",
and so on).

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

Strange.  That's not APL -- this is more like APL:

x <- (2+y) * 7-a

APL (and J, and K) do have a significantly different syntax and semantics,
though, and it has nothing to do with using an arrow instead of an equals
sign.  One interesting part is that normal operators have no precedence;
expressions are executed from right to left.  This results in a nice,
clean, consistent picture where data always flows to the left.

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

And here data always flows to the right.

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

Nor is dataflow.  Symbol manipulation IS.  :-).

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

Yes; fully agreed.  Especially cool about the HP-48 is the fact that the
algebraic evaluator does some pretty typesetting.

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

Could be.  I don't have an opinion, so I've kept silent.  Sorry, but I
don't express opinions about things I don't understand, and I don't think
that's any grounds for offence.

>Tom Novelli <tcn@clarityconnect.com>

-Billy