Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!ucsd!sdcc6!ir230
From: ir230@sdcc6.ucsd.edu (john wavrik)
Newsgroups: comp.lang.forth
Subject: What makes Forth Forth?
Message-ID: <14950@sdcc6.ucsd.edu>
Date: 14 Dec 90 16:41:23 GMT
Organization: University of California, San Diego
Lines: 57


Here are two events from Forml 1990 that inspired some questions on 
the subject of "What makes Forth Forth".

I.
At FORML, Robert Smith told of reading some source code in which the 
phrase "2 DROP" occurred. He found it hard to understand why anyone 
would want to put a literal on the stack and then immediately drop 
it -- so he asked the author. The author's response was that he 
though it would be more useful to have DROP take an argument -- so 
in his version of Forth, "<n> DROP" means to drop the top n numbers 
on the stack. Everyone chuckled.

I thanked God that the author of the code, whoever he is, has not 
managed to sell 500 copies of his version -- which would make him a 
"major vendor" and a power to be reckoned with. [It would be back to 
the thesaurus time on the old X3J14 ranch -- and we might all find 
ourselves using FORSAKE or even CHUCK instead of DROP so that we do 
not break anyone's code.] 

    To what extent is the proper choice of primitive words what makes 
    Forth Forth? Does the proper choice of capabilities at the very 
    lowest level (control over the input stream, control over 
    compilation, control over memory allocation, control of search 
    order, etc) determine the nature of the language. Which words are 
    essential -- which are negotiable -- which are vendor options? -- 
    which are programmer options?  Is the admittedly political method 
    used to produce a new Standard designed to preserve essential 
    features of the language? 

II.
Wil Baden treated us to a one hour presentation to show the 
machinations with extended versions of high level control words that 
are needed to code tangled control flow problems. Baden has done an 
excellent job in showing what is needed if we trade low-level 
flexibility in defining new control structures for an expanded set 
of higher level words (the usual IF, ELSE, etc. together with new 
words like BUT, SO, and ALTHOUGH). [The status of these is uncertain.
I've been told that they have not been accepted in complete form by 
the ANSI committee.]

The use of high level words can be quite awkward for building new 
control structure words. A natural question to ask is why not provide 
BRANCH and ?BRANCH (as found in FIG-Forth and is sucessors) -- from 
which all these and yet other things can be built? Apparently the 
problem is that there is no vendor agreement about the additional 
information that control words put in the stack. Without this 
agreement to make lower level words work, we are stuck. 

   To what extent is Forth Forth because (initially) things were 
   standardized at a low level?  To what extent will Forth lose its 
   power and its character if it is standardized at too high a level? 

                                                  John J Wavrik 
             jjwavrik@ucsd.edu                    Dept of Math  C-012 
                                                  Univ of Calif - San Diego 
                                                  La Jolla, CA  92093