From: braker@ennex5.eng.utsa.edu (Jim Brakefield)
Subject: Re: Forth FAQ Answers: Part 01 (What is Forth?).  (V1.0:01.Jan.93)
Keywords: Forth, software metatheory, address space
Organization: Univ of Texas at San Antonio
Date: Sat, 2 Jan 1993 18:14:28 GMT

In article <4215.UUL1.3#5129@willett.pgh.pa.us>  writes:
> What is Forth?
> 
>  (C) Copyright 1992 by Philip J. Koopman Jr.
>  Original message header:
>     From: koopman+@cs.cmu.edu (Philip Koopman)
>     Summary: HOPL-II Forth language description -- Draft 9/17/92

>  The following is a draft description of the Forth
>  programming language.  It will eventually appear as 
>  a preprint for the History of Programming Languages 
>  Conference (HOPL-II) to be held in Boston in April 1993.
>  That conference will feature an excellent paper on the 
>  history of Forth by Rather, Colburn & Moore.
>  Constructive criticism appreciated.

>  Forth is both an extensible language and an interactive program 
>  development methodology.  While originally developed for small 
>  embedded control mini- and micro-computers, Forth seems to have 
>  been implemented on every major processor manufactured.  It has 
>  been used in a wide variety of applications, such as spreadsheets, 
>  expert systems, and multi-user databases.
> 
>  At the most superficial level, Forth is an almost-directly executable 
>  high-level language for a stack-based abstract machine.  In its 
>  essential form, the Forth abstract machine has a program counter, 
>  memory, ALU, data evaluation pushdown stack, and subroutine return 
>  address pushdown stack.

I wish to comment on Forth as an abstraction of computer programming.
That is: the use of Forth to model other software paradigms.  Granted
Forth is primarily a practical language or tool, I see no harm in also
considering it a theoretical vechicle.

I choose Koopman's description of the normal-perception-of-Forth as a
point of departure.  The metatheory goes something like:
	Justification of the architecture
	Properties of the architecture
	Embeddings of other software paradigms

	Signal space (Boolean logic, gates, & flip-flops) provide the
material for building computers.  Computers are an actual means of 
evaluating expression trees.  Thus the hardware is arranged to provide
a suitable means for expression evaluation (i.e., computation).

	Memory is the means to encode the expression tree and its
run-time support.  Memory is an ordered set of states (memory locations).

	The complete expression tree is folded to save memory.  This
folding (factoring) is via recursion (iteration is a specific form of
recursion, i.e., tail recursion).

	Given that the expression tree is evaluated sequentially, the
dynamic state information can be ordered into a stack.  However it is
better to provide two stacks: a data stack and a return address stack.  

	The return stack is seperate from the data stack in that it 
encodes locations in the expression tree and that it is handy to rewrite 
the expression tree (refactor) as part of the software development process 
(the expression tree does not appear all at once, but must be created
and tested a portion at a time).

The above is a minimal statement of a rational for why computers and their
software environments are the way they are.  Several things emerge:

 Memory economy leads to recursive expression of software.
 The von-Neuman or sequential evaluation mode leads to evaluation stacks.
 The need to refactor the expression tree leads to seperating the data
  and return stacks.

It is a little surprising some of the most "glorious" concepts in computer
science have such humble ancestrey: Recursion is a result of the need to
conserve memory, sequential evaluation favors the stack, and the oldest
debugging kluge in the books, splicing in a modified piece of code via
replacing the code with a subroutine call, leads to seperating the 
evaluation stack into data and return stacks.  (pardon my sinicisum)

Anyway, I welcome discussion on the above, terse as it is.

James Brakefield, braker@ennex1.eng.utsa.edu
Hopeless Forth theoretician