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