Path: utzoo!attcan!uunet!mcvax!ukc!strath-cs!glasgow!orr From: orr@cs.glasgow.ac.uk (Fraser Orr) Newsgroups: comp.lang.postscript Subject: Re: An Idea to Help Make Postscript Easier to Read (and Write) Message-ID: <1619@crete.cs.glasgow.ac.uk> Date: 8 Sep 88 13:32:06 GMT References: <940@helios.ee.lbl.gov> <5361@vdsvax.steinmetz.ge.com> Reply-To: orr%cs.glasgow.ac.uk@nss.ucl.ac.uk (Fraser Orr) Organization: Comp Sci, Glasgow Univ, Scotland Lines: 75 In article <5361@vdsvax.steinmetz.ge.com> barnett@vdsvax.steinmetz.ge.com (Bruce G. Barnett) writes: >I am trying to visualize a language that would let you call >a procedure that returns three values on a stack, then uses two of >them, does some other functions, and then uses the third. >When this is nested, the problem gets worse. Then add variable binding, and >delayed parsing of names. > (a,b,c) = ReturnsThreeValues () UsesTwoValues (b,c) OtherFunction1 (AnotherVariableName) OtherFunction2 () UsesOtherValue (a) >The values on the stack have no names, and the positions change >with every call. The function of the names could change dynamically. Ugh! >I suppose you could convert a PostScript program to >pop all values off the stack, and assign names to each value. >Then all operations would be done with variables. Yes, thats what I do. >But that program would be very inefficent. Herein lies the crux of the matter. Firstly I think it is exaggeration to say that an operation like name binding will make your program very inefficient. Name look up is very fast, name binding just as fast. Overall the loss would be very little (this is of course my opinion based on a little practical experience, it would be interesting to see any figures comparing the efficiency of a "typical" PS program using stack manipulations and using names.) Look at what you gain though. Programs that you can understand, programs that you can debug etc. PS programs are often run only a few times so the amount of time spent writing the program is a much more significant proportion of the time taken to generate the output than is normal with any other programming language. Hence any improvment that can be made in the programability of the system is a considerable *overall* efficiency gain. Using names instead of stack machinations is a considerable improvment on the programability, thus a significant overall effiecency gain. I believe this argument is valid for general programming languages, but is much more so of languages like postscript. >I believe you should master the language. Having a C front end >for PostScript is like having a Basic or Pascal front end for C. > >Yes, you can do it, but you lose so much. The programming language is not to be considered a hurdle to communicating your intent to the computer, but a means by which that communication can be made. The programming language should intrude on your thoughts and design as little as possible. In my experience of reading postscript programs this is not the case. Having a C front end to postscript is not like having a Basic front end to C, but more like having a C front end to 68000 assembler (this isn't mean to be a critisism of PostScript, I'm just trying to say that it is at much lower a level than any human should ever have to deal with.) As for loss. I don't see that you loose much more than a few seconds per page run time wise. Time you can easily regain in reduction in programming and maintanance time. > Bruce G. Barnett Regards, ==Fraser Orr ( Dept C.S., Univ. Glasgow, Glasgow, G12 8QQ, UK) UseNet: {uk}!cs.glasgow.ac.uk!orr JANET: orr@uk.ac.glasgow.cs ARPANet(preferred xAtlantic): orr%cs.glasgow.ac.uk@nss.cs.ucl.ac.uk