Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!intercon!amanda From: amanda@intercon.com (Amanda Walker) Newsgroups: comp.lang.postscript Subject: Re: Compiled PostScript Message-ID: <1690@intercon.com> Date: 8 Jan 90 17:09:56 GMT References: <1666@intercon.com> <1683@intercon.com> <17581@rpp386.cactus.org> Reply-To: amanda@intercon.UUCP (Amanda Walker) Organization: InterCon Systems Corporation, Reston, VA Lines: 74 In article <17581@rpp386.cactus.org>,ntwoody@rpp386.cactus.org (Woodrow Baker) writes: > [I wrote:] > It's kind of like Forth in this respect--writing > code to handle single operations is fine, but I wouldn't want to write a > large application in it, even though it could be done. There have been some mighty large and powerful systems written in FORTH. because of it's extensibility, which it shares with PS, you can literaly build layer upon layer, until you can write an entire GL package with just 1 screen of code. As I said, you can certainly do it, I just wouldn't want to. I mean, people have written airline reservations system in APL, too. I wasn't asking for an existence proof :-). It seems that most people are unwilling to look at PS as anything other than a fancy printer controler command set. Well, I look at it as a quite nice two-dimensional imaging language. It does an extremely good job of making the physical characteristics of the imaging medium irrelevant to the task of describing the image itself. Now, it is a lot like Lisp in being a ball of mud language (i.e., whatever you add to a ball of mud, it's still a ball of mud), principally because it has a very simple syntax balanced by often complex semantics. Sun, for example, has added some marvelous extensions for event handling and lightweight processes, as well as multiple imaging surfaces (called "canvases") and object-oriented method dispatching (which will also work just fine in vanilla PostScript). I challenge you to pinpoint *ANY* major deficiency of PS for general purpose programming. - Named and lexically scoped local variables and parameters. These can be simulated by using anonymous dictionaries that are patched into executable arrays, but this is a hack. - A more sophisticated model of memory management. A garbage-collecting storage management subsystem would make it much easier to implement complex data structures using dictionaries (a la NeWS) and to use persistent data structures in general. 'save' and 'restore' work great for throwaway code, or code that is executed on the fly (as most PostScript code is), but it suffers when you are using more persistent data structures, especially if they can change in size. To take a concrete example, I would find it much easier and more pleasant to write a B*-tree manipulation package in C or Lisp than I would in PostScript. The 'right' way to write something in PostScript that used a database would be to add primitives to the interpreter I was using to do the low-level memory and file management. - A more sophisticated I/O model. Things like random access to file contents become important for general purpose programming. The file system primitives provided with PostScript so far are designed for storing hunks of PostScript code (be they fonts or whatever), and they are pretty good at it, but sometimes you need more than simple text streams. There is no reason, other than predjudice, that one could not implement say a mailing list manager, using the hard disk, and generating forms and labels within the printer. There is no reason that one *could* not, but there are many reasons why one *would* not, not the least of which is that since you probably are using a computer of some sort to give the printer commands, you may as well use it for what it's good at. Drawing labels and forms is quite appropriate for PostScript. Database management, however possible in a theoretical sense, is not, given the current set of primitives that are defined as "PostScript." The fact that many languages are Turing-equivalent does not mean that they are equally suited for any given task :-). Imagine describing pages in assembler, for example...