Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ames!mailrus!eecae!raisch
From: raisch@eecae.UUCP (Rob Raisch)
Newsgroups: comp.lang.forth
Subject: Forth "Pre-Compiler" (Long)
Keywords: Design Development Forth Compiler Object Oriented FAD
Message-ID: <10036@eecae.UUCP>
Date: 15 Jul 88 22:52:44 GMT
Reply-To: raisch@eecae.ee.msu.edu (Rob Raisch)
Organization: Mich. State Univ., Electronics R&D Laboratory
Lines: 172


I have been thinking about threaded interpretive languages recently and
would like to share a few of my thoughts with the newsgroup.

I have been a `forthHacker' for a few years and have developed a few
large, sophisticated applications.  Since I also have keen interest in
other languages, and most specifically, `object oriented' languages, I
have felt that Forth was sadly lacking in a few areas.  Before I explain
what I mean, let me explain what I think I know.

Design Requirements for a Forth Language:

	First and foremost, Forth must be small/compact/efficient.  This
	concept has driven Forth from the early days, and is still quite
	an important concern today.

	Forth must be portable.  This has been accomplished by various
	`standards committees', and Forth exists as a `standard' language
	for the most part.

	A subset exists of what we all know and love as `Forth' which I
	shall call `Pure Forth'.  Any implementation of Forth must, at
	it's lowest level, support `Pure Forth'.

Given these understandings, (which I hope are all correct), there are
certain areas of the Forth language that have not grown much in the
intervening 20 or so years that Forth has been around.  I have had a
true `love/hate' relationship with Forth because of these `shortcomings'.


Why I LOVE Forth:

	It is FAST! -- Above all else, Forth is one of the fastest
	executing languages around.  Since it is functionally both a
	compiler and an interpreter, this speed is evident both in the
	execution of the program and in it's compilation.  The speed of
	Forth also makes for rapid prototyping.

	It is ELEGANT! -- Most of the implementations of Forth share a
	cleanliness of paradigm that I find quite pleasing.  Programs
	developed in Forth tend to be quite `bugless' because of this
	`oneness of vision'.

	It is SMALL! -- We all know this one.  Forth is a tiny language.

	It is POWERFUL! -- Forth includes a flexibility of control that,
	I believe, is unprecedented in most programming languages,
	(except, perhaps, for Lisp).

Why I HATE Forth:

	Postfix Notation -- Yes, I know this one has been done to death.
	Mr. Moore, himself, has taught us that `infix notation' is not
	the natural state of creative thought, but an arbitrary decision
	of the educational community.  Whether or not you agree with
	this, most humans that I have known think in `infix'.  This is
	the way in which we have been taught, from a very early age, to
	deal with the complexities of mathematics.

	Linear Definition -- Forth has virtually no mechanism to deal
	with memory/vocabulary management.  The `flat/linear' structure
	of the Forth dictionary has been modified, in the past, to
	handle `hierarchical dictionaries', with multiple branches off
	of a `root' dictionary.  I believe that this has held Forth
	programmers in chains for far too long.  The fact that a
	programmer can `re-code' a word in Forth, but that that new
	implementation is not `seen' in the old context is quite
	limiting.

	Lack of Decent Development Tools -- Well, this one is a favorite
	bug-a-boo of mine.  Coming, as I do, from a Unix environment, I
	can appreciate the fact that Forth can support a full screen
	editor, but is this as far as we have gotten?  What about
	parsers, prettyPrinters, macro-preprocessors, etc.

Ok, now that I have gotten that out of my system, let's talk turkey.

The problems with Forth, as I see them, are not with the `run-time'
engine.  Forth is marvelously designed for the speedy and efficient
execution of programs.  The problems are created when we attempt to
develop code in this environment.  Forth has been called a `programmer
antagonistic' language and I concur.

What we need is a `development environment' that benefits the
programmer, not works against her/him.  This is what I propose:

Forth Application Developer - FAD

	Supports the full `Pure Forth' language, but in an environment
	that supports a new dictionary structure that is laid out like:

		Word Hash Table -- used by the interpreter to locate an
		`object' in a fast efficient manner.  Entries in the
		Hash Table point to the Name Table.

		Name Table -- contains all of the information used to
		describe a particular object and points to the Object
		Table.  This information is allocated on the computer's
		heap and can be changed interactively. (If FAD is used
		as an `execution engine', both the Name Table and the
		Hash Table are stripped, since they are not needed in an
		executing program.)

		Object Table -- forward links to the particular objects
		data space, and a backward link to it's Name Table entry
		to facilitate `reverse compiling'.  The Object Table
		entry also contains a `reference count' to allow garbage
		collection by the interpreter.

		Heap -- this is where an object's data space is kept.
		Since the Heap is managed by the interpreter, space used
		by `de-referenced' objects can be reclaimed and re-used.

	Supports an `infix' notation of Forth, (and should ultimately
	support an `object oriented' notation, as well.)

	Produces the application written in `Pure Forth'.

	Supports `relocatable' libraries of definitions, allowing
	development of `packages' which can be loaded `on the fly' and
	partially unloaded to conserve space.

Benefits:

	Since the standard Forth `dictionary' has been redefined, Forth
	objects can be defined, re-defined, saved, reloaded, and
	destroyed based on the needs of the programmer.

	A new `infix' syntax allows the programmer to create complex
	programs following current programming paradigms, without the
	need for the programmer to act as his/her own language/concept
	`preprocessor'.

	Entire systems can be `cloned' and saved `in toto'.  This allows
	historical `revision' control.

	When the application is complete, the FAD produces Forth code
	that is transportable across many platforms.

I guess what I find most disagreeable about the Forth development philosophy 
is the fact that most developers use the `target' machine as a `development'
machine.  We should maintain the `purity' of the Forth `execution engine', 
but we should not let that limit the programming/development environment.  I 
feel that the progression of the Forth language has been `held back' because 
of the rational requirement that Forth remain a fast/efficient/small
programming language.  Perhaps it is time to treat Forth as a `target'
for which we compile programs using higher-level programming tools.

FAD is only slightly more than a dream.  I have done some considerable
design of how I believe it _should_ operate, but I have yet to really put
an effort into writing it.  

Should FAD be written?  If so, should it be written in `C' or should I
tackle it in Forth?  

I am very interested in comments about these concepts.  Of course, I
would like this to stimulate others to think about the `execution
engine' versus the `development engine', but I would also like some
feedback about FAD.  If you feel that this work would benefit the Forth
community or you have problems with these concepts, I would certainly like 
to hear from you.  Responses mailed directly to me will be abstracted to
the net.

Oh, by the way, my ultimate plans for FAD are to release it into the 
public domain.

----------------------------------------------------------------------
Robert Raisch -  Systems Programmer/Researcher/Language Nut
CASE Center for Computer Aided Design and Manufacturing
(517-353-4841)  Michigan State University, East Lansing Michigan 
raisch@eecae.ee.msu.edu    |  raisch@msudoc.egr.msu.edu
{backbones}!msudoc!raisch  |  {uunet}!umix!mnet!raisch 
----------------------------------------------------------------------