🚀 go-pugleaf

In article <1619@crete.cs.glasgow.ac.uk> orr%cs.glasgow.ac.uk@nss.ucl.ac.uk (Fraser Orr) writes:
>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)
>

I think the point Bruce is trying to make here is that high-level languages
such as C remove you from the concept of maintaining and operating on a
stack.  Sure, you can write functions like the ones shown above, but
what have you gained?  You still need to maintain an knowledge of what's
on the stack at any given time.  To really implement a high-level front
end, you would need to manage the stack for the user, which is what any
high-level language does.

So why not write a high-level language that manages the stack for
the user and gives the appealing fluency of C ? 

I'll tell you why.  PostScript is an interpretive language.  That is
the chief reason it was developed in postfix notation.  Anyone who has
used an HP calculator can tell you that postfix is more efficient.
Were it a compiled language, then high-level is the way to go.  However,
interpretive languages should not be high-level, because of the added
burden of maintaining a stack - look how inefficient BASIC is!
The high-level language that could do all this for PostScript would
most certainly crawl, since functions would have to maintain variables
rather than use the stack - a loss in memory and CPU cycles.
I think that PostScript does an excellent job at what it was designed
to do.  It's an interpretive page description language, not a high-level
complied language (which has the luxury of compiling to machine code where
stack management is not as costly).  It also affords much freedom in
programming, allowing graceful stack gymnastics to make programs more
efficient.

Just my point of view...

-Craig

--
Craig S. Cochran <cochran@ge-dab.GE.COM> 
                                            General Electric Company
UUCP:   ...!mcnc!ge-rtp!ge-dab!cochran      1800 Volusia Ave, Rm 4112
Phone:  (904) 239-3124                      Daytona Beach, FL 32015