Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!mcvax!kth!sunic!dkuug!iesd!fj
From: fj@iesd.dk (Frank Jensen)
Newsgroups: comp.lang.postscript
Subject: Dealing with large procedure bodies (Another method?)
Keywords: The Green Book
Message-ID: <1805@iesd.dk>
Date: 5 May 89 18:00:32 GMT
Organization: Dept. of Comp. Sci., Aalborg University, Denmark
Lines: 50

The problem of dealing with large procedure bodies is treated in
detail in the green book by Adobe.  This book gives two ways of
splitting a large procedure body in order to avoid operand stack
overflow.


The first method is to replace a procedure definition such as

	/x {a b c d e f g h i} def

by a number of named procedures:

	/r {a b c} def
	/s {d e f} def
	/t {g h i} def
	/x {r s t} def


The second method (which is better in case you are generating the
procedure from a program) is as follows: The definition of `x' now looks like

	/x [{a b c} /exec load
	    {d e f} /exec load
	    {g h i} /exec load] cvx def


However, this method seems to be unnecessarily complicated.  The
following definition of `x' seems to work:

	/x {{a b c} exec {d e f} exec {g h i} exec} def


According to my comprehension of the execution model for postScript,
this should work (and indeed it does!).  Obviously, the postScript
interpreter has to keep track of how many unmatched left braces it has
seen, and so the question is when a pair of matching braces is
converted to a procedure (an executable array).  The most natural
place to do this is when the matching right brace is found; this
conversion into an executable array will thus free a lot of operand
stack elements, leaving space for scanning the next subprocedure.
(Section 2.7 in The Green Book seems to confirm this.)

Am I wrong about how the scanning/interpretation process is performed?
If I am, then please feel free to tell me so.


Frank Jensen,   fj@iesd.dk
Department of Mathematics and Computer Science
Aalborg University
DENMARK