Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!willett!dwp From: dwp@willett.UUCP (Doug Philips) Newsgroups: comp.lang.forth Subject: Re: Why is Postscript not Forth? Message-ID: <450.UUL1.3#5129@willett.UUCP> Date: 12 Feb 90 01:32:24 GMT References: <7228@sdcc6.ucsd.edu> Organization: Latest link in the ForthNet chain. (Pgh, PA) Lines: 170 In message <7228@sdcc6.ucsd.edu> ir230@sdcc6.ucsd.edu (john wavrik) writes: > 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). I was hoping to avoid this kind of answer. It leaves one open to the question: What about the incompatabilites of the various 'dialects' of Forth (fig-Forth, Forth-79, Forth-83, etc.)? What is it about those dialects which allows their differences to be dismissed, but the the differences between "Forth" and "PostScript" to be important. > The underlying question of "the essence of Forth" is more interesting. Yes! > 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). Ok, I'm confused. If, as you seem to imply here, Forth is 'what a programmer thinks about when he writes programs', how does the underlying implementation language make one whit of a difference, so long as it provides access to the hardware in an equally convenient way? > II. [Wavrik states here the view that "Forth is 'assembly language done right!'" and points out problems with traditional assembly language(s): Dependence on a particular processor. Lack of an interactive programming environment. Programming constantly stays at a low level (dealing with memory, registers, etc.)] > In this point of view, Charles Moore performed a miracle: > ... 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). When you say 'have also provided', are you implying that 'CODE' is not part of the "essence" or "fundamentality" of Forth, or are you saying that it is one aspect of that essence? > 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. This seems straightforward, and, also seems *not* to conflict with the idea that the virtual machine can be written in another high-level language, so long as the access to the 'real' hardware is convenient. > 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. Two points: a) how do the 'Forth in C' implementations fail at this? b) perhaps Forth and PostScript are different only in the ability to get to the real hardware? > 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.] Again, two points: a) how is this (necessarily) more true of Forth than of PostScript? b) Forth seems to be losing its unique-ness, by this definition, with the growing encroachment of 'C' into domains previously held strong by Forth. 'C' which meets all those criteria. > 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. Would you argue then that the part of Forth which is allows you to "redesign the 'chip'" is not essential to the nature of Forth? Is it just an unfortunate side-effect of Forth's simplicity, or it part of what makes Forth Forth? > 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. Is this the "not invented here/my way is better" syndrome or is it language evolution? Was Forth already perfect? > 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. True to the extent that X3J14 is charged with "codifying existing practice." Language design is not effectively done in the ANSI forum. What you seem to be missing here is not that 'the user is not allowed to know anything about the architecture of the chip,' but the user is made aware of what aspects of Forth are dependant on the underlying hardware and *may not* be portable across different complying implementations. When you say Forth was 'one of the most highly portable languages', you are either saying that the virtual machine itself is highly portable, but not Forth programs, *or* that Forth programs were highly portable only because the only places you could port them too, the actual hardware platforms, were so alike. X3J14 is not making things 'unportable', all they are doing is enlightening you as to what is already or is likely to be unportable. One of the most amusing things about the 'C' (X3J11) effort was how people would scream about how ANSI broke 'X', when in fact all ANSI did was point out that 'X' was already nonportable. > 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). I'm close to an answer here! ;-) I was definitely trying to avoid PostScript as a page layout language and stick to "essence of PostScript", because I suspect that it is not the page layout 'extensions' to PostScript which make it unForthlike, but rather some more fundamental issue which distinguish the two. From section 'I' above: > 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). Is the visible characteristic of PostScript's mixed-element stack indicitive of an underlying and fundamental difference between Forth and PostScript, or is it inconsequential difference? What are the fundamental differences? -Doug --- Preferred: willett!dwp@gateway.sei.cmu.edu OR ...!sei!willett!dwp Daily: ...!{uunet,nfsun}!willett!dwp [in a pinch: dwp@vega.fac.cs.cmu.edu]