🚀 go-pugleaf

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 	<barnett@ge-crd.ARPA> <barnett@steinmetz.UUCP>

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