Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!princeton!caip!topaz!uwvax!astroatc!philm
From: philm@astroatc.UUCP (Phil Mason)
Newsgroups: net.lang.forth
Subject: Re: The Flip side of Forth
Message-ID: <450@astroatc.UUCP>
Date: Mon, 23-Jun-86 11:28:49 EDT
Article-I.D.: astroatc.450
Posted: Mon Jun 23 11:28:49 1986
Date-Received: Wed, 25-Jun-86 05:30:44 EDT
References: <9100009@uiucdcsb>
Reply-To: philm@astroatc.UUCP (Phil Mason)
Organization: Astronautics ATC, Madison, WI
Lines: 150

In article <9100009@uiucdcsb> liberte@uiucdcsb.CS.UIUC.EDU writes:
>
>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?
> . . .
>
>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 . . .
>Yes, you may write your own lexing tool, but you have to do it in Forth.

To expect more of Forth's outer interpreter is to expect more of any feature
of the language. Forth is simple, yet versatile. If you really want to make
a new parser, fine. You don't have to do it in Forth, you can do it in assembly
language.

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

This is a very valid point, but one that can be said of many languages that
are not as rigid as C or Pascal. BASIC is unmanagable in the sense of 
structure. Forth is flexible in the sense of parameter passing. Sure, keeping
track of the stack is a pain, but the other side of the coin is that well
constructed words and applications can be a pleasure to use because of the
simplicity of the syntax.

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

If you want to modify the way Forth works, it is quite easy to Meta-compile
a new copy with any extra bells and whistles (or necessities) that you desire.

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

I agree. The editors do stink; however, they are a hell of a lot better than
having no editor at all or having a more rigid operating system and language
where a substantial effort would be required to write a new one. Editors are 
one of the first things that are rewritten by the owner of a Forth interpreter.
Sure you have to rewrite an editor in the present editor. What do you expect?
Most editors are very short, a dozen screens or so - even the screen-oriented
ones. 

Screens (Blocks) represent the most rudimentary form of disk management.
The concept of screens are, however, portable and extremely easy to implement
on a new computer. Using a screen as a fundamental unit of source code chunk
yields some benefits. For example, you will not find a word that is longer than
a screen in length (although it is possible, it is bad style). Screens should
not be packed with too much information. Come on, a little white space does
wonders for any source code and comments. In this day and age of quad density
disks, we have disk space to burn. Shadow documentation screens are a neat
idea. Essentially every code screen has a documentation screen that is edited
in parallel with the code. The shadow screen is called up automatically upon 
calling up a source screen for editing.

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

I think you are expecting way too much of a simple system. Forth is 
simple, portable and versatile. Why would you want to add messy memory 
management to Forth? LISP really can't be used in real time situations because
of garbage collection. To each his own - Forth can be hacked any way you want.
If you go too far, you lose alot of the advantages of Forth.

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

Error processing is left out so that you can put it in - if you want.
Forth's data structure tools are versatile enough to add any types you desire - 
if you need them. The variety of operators is due to the fact that Forth 
has tools for every primitive data type. The names are mnemonic, much like
assembly code. If one were to tag each datum on the stack with a type,
every word in Forth would be much more complicated with little advantage.
The sparseness of the system documentation is indicative of the grass-roots
beginning of Forth. It's getting better, though. 

I'd rather code in Forth than assembly language, any day.

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

If you have ever designed a major piece of software and have tried to maintain
it, you should realize that there is no substitute for good code and good
documentation. Forth or any other language can be readable or unintelligable.
It's your choice. I think it is a bit narrow to single out Forthers as being
the font of bad style.

It seems that what you wanted to do was to radically restructure Forth.
If you go too far, you lose all of the simplicity, portability and versatility
of Forth. You end up with a system that can not be called Forth and does not
share its advantages. Try restructuring LISP or C or Pascal if you want to
really run into a wall.

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

This sentence is what I really take exception to. Why the hell do you want to
warn people away from Forth? You asked too much of a very simple language
and now, because of your attitude, you will dissuade others from experiencing
their own journey of discovery. Maybe that person will like Forth, maybe not.
You have expressed the opinion that Forth is not for you. That's fine. 
Please don't tell other people that Forth is a crock because you were not able 
to get your ideas to work with it. That is quite unfair.

You were more open-minded about Forth than most. Alot of people dismiss Forth 
without really trying it. It is important for people to try something before
abandoning it. Forth is not for everyone, but for those of you who are 
interested in further readings about Forth and its relationship to other
pools of thought, try these books :

"Starting Forth" and "Thinking Forth" by Leo Brodie.
"Forth Fundamentals Volumes 1 and 2" by C. Kevin McCabe.

"Forth Fundamentals" and "Starting Forth" give descriptions and introductions
to Forth itself. "Thinking Forth" gives a good description of Forth and its
advantages, philosophy and relationship with other languages and philosophies.
"Thinking Forth" also includes chapters on applications development and good
Forth style and documentation standards to follow.


-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Kirk  : Bones ?                |  Phil Mason, Astronautics Technical Center
Bones : He's dead Jim.         |  Madison, Wisconsin - "Eat Cheese or Die!"
- - - - - - - - - - - - - - - -|  
...seismo-uwvax-astroatc!philm |  I would really like to believe that my
...ihnp4-nicmad/               |  employer shares all my opinions, but . . . 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=