Path: utzoo!utgpu!attcan!uunet!mcvax!ukc!strath-cs!glasgow!orr
From: orr@cs.glasgow.ac.uk (Fraser Orr)
Newsgroups: comp.lang.forth
Subject: Re: Forth "Pre-Compiler" (long)
Message-ID: <1563@crete.cs.glasgow.ac.uk>
Date: 8 Aug 88 16:34:25 GMT
References: <8808032106.AA01436@jade.berkeley.edu>
Reply-To: orr@cs.glasgow.ac.uk (Fraser Orr)
Organization: Comp Sci, Glasgow Univ, Scotland
Lines: 142

There have been many interesting responses to my earlier articles on this
subject, and I would like to reply to them all in detail, but I don't come
here merely to write articles in comp.lang.forth! I'll follow up to Lee
Brotzman's excellent article and hope to answer the rest of your comments in
so doing.

In article <8808032106.AA01436@jade.berkeley.edu> ZMLEB@SCFVM.BITNET (Lee Brotzman) writes:
>
>not the answer.  I tend to disagree, however, when he asserts that Forth
>distracts from thinking about the problem.  By the time one is ready to write
>code, the problem had better be solved already, otherwise, no language
>is going to help.  That's what the modern software design methods teach us,
>anyway.

True. The purpose of a programming language is to describe precisely this solution
in a way that is clear primarily to the people who are going to maintain the
program, and secondarily to make it easy to type in.

>   As for program readability, I can take any language and make it completely
>unintelligible, what does that prove?  To argue whether it is easier to
>write unreadable code in one language or another is silly.  The point to
>make is that code should be readable, period.  Mr. Orr has admitted that he
>hasn't used Forth for some time.  That's no crime, but perhaps his attitude
>would soften a little bit if he were introduced to the more recent advances
>in the language's constructs (by recent I mean in the last five years).
>
Yes, this is a point many people have made. I accept that the example I gave
was pretty unfair. But if you look at a fairer comparison

int Fact ( n )                    : Fact      ( n -- n! )
{                        VS         Dup
  if ( n > 0 )           --         0= If
    return n*fact(n-1)                Drop 1 Exit
  else                              Else
    return 1 ;                        Dup 1- Fact
				      *
                                    Then
				   ;

Given by David Murray, then I think my point is made most succesfully.
If we look at a good peice of Forth code we get lovely lines like
"Dup 1- Fact *" and I'm sorry to say that I cannot accept that that is
anywhere near as clear as "n*fact(n-1)". Yes I accept that with practise
it becomes much easier, why put the extra mental load on yourself of
having to maintain a picture of the top of the stack, when you could
(as the C does) keep it all above board.
If I see something like "while(*s) *s++=*p++" in a C program, I understand
it, but that doesn't make it nice.
Some people might say that this is trivial, but I just don't agree,
in the same way that if I slur my speech or misspel my wardz it puts
a barrier between you and me, if there is this extra mental decoding going
on in programming, you are moving one step closer to the code and one
step farther away from the meaning of the program.
What is the objection to having infix operators?

People have also said that forth is generally written much better than
C and other such languages. This is true, and as someone else said it is
pretty tough seperating the programming language from the way it is
idiomatically used. But for people who are interested in programming
languages this is an effort that must be made. We must find out what is
good about a language independently of the way it is used (it would also
be interesting to know what makes people use a language badly, but that's
a different story)
>   Use of multiple-code-field named variables reduces or eliminates the need
>for the @ and ! operations by imbedding them into the word itself.  A variable
>is defined like before, except with an initial value: "0 VAR TEST".  When
>TEST is executed, it pushes its *value* on the stack, like a constant.  To
>store a new value in TEST one can say: "10 TO TEST".  To get the address of
>TEST, one can say "AT TEST".  The use of English verbs to describe the actions
>enhances readability, and the implementation of these words has actually
>proven to be faster than the traditional @ and ! way of doing things.
>
This is interesting, I can't even imagine how it works! Certainly though this
is a step in the right direction. Your right that the last book I read on forth
was on Forth83, which was before your stated time limit.

>   Several Forths have implemented full data structure defining words which
>are analogous to C's struct and Pascal's RECORD.  The syntax is clean and
>as readable as either of the other langauges.
>
Interesting. This leads to another question I have. You tell me that forths
have improved a great deal over the past few years. Have type sytems come
into being yet? It is certainly possible since PostScript has a type system.
Records are only a syntactic sugar ( which is in itself a good thing) without
a supporting  type checker (of course at this stage C bites the dust!)
Have these structures been incorperated into a standard? If not then for most
applications you can't really think about using them.

>   There are also "local variables", which assign names to input stack items
>at compile time.  These can be used in lieu of the "DROP SWAP FLOP PLOP"
>stack thrashing phenomena.  This does wonders to improve the readability
>of the code.  Here, too, execution speed has been shown to be improved
>especially in those words which do a lot of stack thrashing.
>
:-) Horray! This is another step in the right direction. Unfortunately 
if I may quote your later article on this subject.

   For simple, one- or two-line words (the kind of Forth words everyone
   should strive to write anyway), the use of local variables does not help
   that much.  A Forth programmer should train himself to visualize at
   least a three-deep stack in his head.  By using comments with stack
   pictures, it is relatively easy to keep track.

:-( Why? If you need pictures to keep track you need named local variables.

>   (One could argue that if C is so much easier to use than Forth, why have
>C programmers spent years writing development tools, while Forth programmers
>seem to get along just fine with only an editor -- could it be that Forth is
>so easy to test and debug that no expensive development aids are necessary?
>On top of this, the Forth compiler, i.e. the outer interpreter, can be
>modified to one's own needs, so the compiler itself becomes the most important
>development tool, ala the "integrated environment" so many other compiler
>vendors are promoting of late.)
>
If I were being equally glib(-:) I might ask, how come if forth is so much
easier to program in, have forth programmers not managed to produce these
essential tools in and for forth?

>   I have only given a glossy -- and fuzzy -- overview of some of the
>things that help make Forth easier to use and more powerful to code in.
>I am not saying that Forth is a be-all and end-all; so far, I have yet
>to find a programming language that is.  I just want to see it get a
>fair shake, and not be judged solely on its past.  By its very nature,
>Forth is a constantly and rapidly evolving beast.  It can be extremely
>advanced and complex, or incredibly simple and small.  How can anyone
>pin a single label on it?

Equally if it is so fast evolving how can anyone get down to actually using
the features that are being added. I agree that there is no such thing as the
idea language (and anyone out there who has the idea that I think that C is
the best programming language, please change it, your ruining my reputation:-)
but I feel that forth is really too low level to be much use except in very
special cases. But in those special cases (such as PostScript, epsecially if
prvided with a good preprocessor) it is great.

I should say further that I have been very interested in the stuff about the
NOVIX chip. It sounds a prety impresive beast. I wonder how that sort of
technology could be applied to "general microprocessors"?

==Fraser Orr ( Dept C.S., Univ. Glasgow, Glasgow, G12 8QQ, UK)
UseNet: {uk}!cs.glasgow.ac.uk!orr       JANET: orr@uk.ac.glasgow.cs
ARPANet(preferred xAtlantic): orr%cs.glasgow.ac.uk@nss.cs.ucl.ac.uk