🚀 go-pugleaf

We've heard about some of the good things of Forth.  
I would like to turn the discussion around a bit and ask, if Forth
is so good, why isn't it being used?

First, one advantage I would like to expand on is the extensibility feature. 
Not only can you add new words to the dictionary, but you can also add
new defining words. 

A defining word is like other words except that it is used in defining
other words (including other defining words).  Generally, execution of a
defining word will interrupt the normal flow of execution/compilation
and start adding a new word to the dictionary.  When you create your
own defining word, you must specify not only what to add to the dictionary
when the defining word is executed (to define some new word), but you
must also specify what happens when the newly defined word is executed.

This is a powerful, general feature that attracted me to investigate further.
I was driven to learn how to use this extensibility to go beyond 
the starting point of Forth's rudimentary reverse polish notation
and to possibly define more familiar, powerful, higher-level-languages.
Other people have done as much, but what I learned in the process killed my
enthusiasm.

Some of the problems:

The basic lexing/parsing tool is to read the next "word" into a buffer up
to a specified character, usually a space.  Only one such character
may be specified.  Thus words are usually space separated.  Yes, you
may write your own lexing tool, but you have to do it in Forth.

There are a few prefix or infix operators, but Forth is almost entirely
postfix.  This is as bad as Lisp's prefix orientation, only without the
parentheses to guide you in figuring out what you are doing.
You have to maintain the parameter stack manually, a trick business
even for the experienced.  I imagine that coding in p-code would
be a similar experience.

The inner interpretor discussed in other notes which evaluates the
threaded code basically takes control of the operation in such a
way that it prohibits you from modifying the way in which it executes.
This is complicated to explain, but it prevents one from writing a
stepping debugger.  It has to be built in from the beginning.
So you are limited to the old edit/compile/execute cycle, although
you need only recompile the definitions you change.

But the editors generally stink.  Definitions are kept in one file of blocks,
each block is 16 lines by 64 characters, space filled (so you waste the
space at the end of lines unless you fill them up with comments which are
needed heavily).  Usually you work with one block at a time.
Yes, you may write your own editor, but you have to do it with the
editor provided.

Memory management is stack management.  You add definitions and data structures
at the end of the dictionary only, and then you may "forget"
everything back to some definition.  That's it. Unless you do major surgery.

What else?  Error processing is usually left out.  The primative data
structures are integers reals and vectors.  No strings unless you
add them.  No records unless you add them.  Words may not be overloaded
so there is a host of addition operators, for example, one for each data type
with funny names like +D or +F or +A.  There are hundreds of primatives
to look up in the sparce documentation.

The whole orientation of Forth is so space conscious at the expense of
readability and maintainability that those people who get into using
and developing Forth also don't seem to care about going beyond what
is given.  They like it as it is.  So as far as I am concerned, there
is almost no support for what I want(ed?) to do.

Take this note as a warning of what you are getting into if you
are attracted to Forth as I once was.


Dan LaLiberte
liberte@b.cs.uiuc.edu
liberte@uiuc.csnet
ihnp4!uiucdcs!liberte