Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!usc!ucsd!sdcc6!ir230 From: ir230@sdcc6.ucsd.edu (john wavrik) Newsgroups: comp.lang.forth Subject: Re: Why is Postscript not Forth? Summary: Essence of Forth Message-ID: <7228@sdcc6.ucsd.edu> Date: 11 Feb 90 04:03:09 GMT References: <431.UUL1.3#5129@willett.UUCP> Organization: University of California, San Diego Lines: 128 In
Doug Philips asks: # In trying to understand the essence of what 'Forth' is, I've been # trying to understand why many Forth supporters don't want to call # PostScript Forth. The obvious answer is because PostScript is not Forth -- Forth programs do not run on Postscript systems and Postscript programs do not run on Forth systems. While the two languages have some characteristics in common, they are different languages (and the people at Adobe claim that their language was conceived before they were aware of Forth). The underlying question of "the essence of Forth" is more interesting. One thing that has become apparent to me during the past year is that "Forth" is being applied to a wide variety of things. I. At one extreme are those who believe that a language is what you print on paper or put in a file (as opposed to what a programmer thinks about when he writes programs). They see Forth as being distinguished by the use of a stack, Reverse Polish syntax, and an interactive environment. The two "Forth written in 'C'" products I have examined this year are both of this type: they have a Forth "look and feel" but lack the power and strength that have led Forth users to select Forth. I suspect, therefore, that the "essence of Forth" does not lie in the use of a stack, RPN, and interactive nature (although these are visible characteristics). [I should mention that these products may have some benefits, in spite of their shortcomings as versions of Forth: they could be useful in providing 'C' programmers a modest interactive environment for running their programs -- they are more of interest as extensions of 'C' than as implementations of Forth.] II. At the other extreme are those who see Forth as "assembly language done right!". Two major advantages of programming in assembly language are the ability to access hardware and the ability to construct languages -- both flowing from a very low level interaction with a computer. The main disadvantages of assembly language programming are: 1. Dependence on a particular processor 2. Lack of an interactive programming environment 3. Programming constantly stays at a low level (dealing with memory, registers, etc.) In this point of view, Charles Moore performed a miracle: he showed how to define (in software) a computer which can be easily mapped to any real processor; and an assembly language for this (virtual) computer which is interactive and provides a uniform blend with a high level language. Moore combined the advantages of high level and low level languages by creating a software pseudo-processor and designing an appropriate language for it. He (and his followers) have also provided a mechanism to integrate assembly language (CODE) definitions into the language where the access to the hardware or host operating system provided by the virtual machine is insufficient (or where greater speed is needed). Forth is a combination (software-realized) processor and language. It is probably this that accounts for most of the uses of the language, and for most of the subjective sense of its power. Forth is most easily understood if it is thought of as analogous to a real processor/assembly-language pair -- rather than a conventional computer language. Assembly language instructions only make sense in the context of the architecture of the underlying "chip". Assembly language is understood in terms of semantics (what action is to be performed) rather than syntax (how something is said). Thus assembly languages are not defined by BNF diagrams but by glossaries of actions. I feel that the "essence of Forth" will be found in contemplating the idea of a virtual computer, the realization of this computer in hardware, the blending of a low level language with a high level language, and (as a philosophical note) the importance of simplicity. Forth is a unique language. Manufacturers provide us with a wide diversity of hardware and operating systems. Forth has provided a viable way to retain the power of low level access without substantial sacrifice of speed and with a great deal of machine independence. The main idea is to substitute an imaginary (virtual) machine for the real machine -- and devise a suitable language for it. [I recommend a study of the design of this machine and its language to anyone -- it is a stroke of brilliance.] III. At this point we interject a major problem to be faced by Forth: Unfortunately, rather than building on the architecture of a single software "chip" (virtual machine), some people have decided that redesigning the "chip" itself would better suit their needs. As a result, the Forth community is now confronted with a variety of Forth- like assembly languages for a variety of "chips" -- destroying the high degree of portability that Forth once enjoyed. It is ironic that the Forth community should choose to artifically introduce incompatibilities at a higher level -- turning one of the most highly portable languages into a chaos. The ANSI effort does not really address this problem. The team is responding by specifying a greatest common denominator of existing implementations. The net result is like trying to provide an assembly language in which the user is not allowed to know anything about the architecture of the chip. FOOTNOTE: My main exposure to Postscript is as a page-description language built in to a laser printer. I have not found a free-standing version of the language presented as a general computation language -- and my department is unwilling to let me tie up the laser printer for language experiments. So this is a summary based on the production of a Postscript driver for graphics programs. Postscript is like a Forth application designed for a special purpose -- to arrange for the layout of elements on a printed page. It would probably not be very difficult to write such an application in Forth. Postscript is like Forth in that it uses a stack and Reverse Polish syntax, a dictionary, etc. A Forth programmer who needs to make a laser printer do something unusual will not find the language hard to learn. It does have interesting features (e.g. the stack can contain elements of mixed type). John J Wavrik jjwavrik@ucsd.edu Dept of Math C-012 Univ of Calif - San Diego La Jolla, CA 92093