Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!uxc!tank!mimsy!brillig.umd.edu!don
From: don@brillig.umd.edu (Don Hopkins)
Newsgroups: comp.lang.postscript
Subject: Re: Dealing with large procedure bodies (Another method?)
Keywords: The Green Book
Message-ID: <17408@mimsy.UUCP>
Date: 10 May 89 07:33:11 GMT
References: <1805@iesd.dk> <820@adobe.UUCP>
Sender: nobody@mimsy.UUCP
Reply-To: don@brillig.umd.edu.UUCP (Don Hopkins)
Organization: U of Maryland, Dept. of Computer Science, Human Computer Interaction Lab
Lines: 89

In article <820@adobe.UUCP> greid@adobe.COM (Glenn Reid) writes:
>In article <1805@iesd.dk> fj@iesd.dk (Frank Jensen) writes:
>>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 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
>
>Well, as the guy who wrote all that stuff in the Green Book, I feel
>compelled to respond.  You're right.  This works fine, accomplishes the
>task of collapsing procedure bodies, and is cleaner than the
>square-bracket version.
>
>There is one advantage to the square-bracket technique.  You can ALWAYS
>put the square bracket on the stack (it is equivalent to a "mark") if
>you aren't sure how big the procedure will be (for instance if it is
>being generated by software).  Then you cover yourself.  If the
>procedure is short, you can put the whole thing in one procedure and
>just "pop" the mark off the stack.  Otherwise, if your front-end
>software does not look ahead, you might end up with a lot of these:
>
>	/x { { a b c } exec } def
>
>which can get pretty inefficient and messy.  If you use the '[' method,
>it would look more like this for short-enough procedures:
>
>	/x [ { a b c } exch pop def
>
> [...]
>Regards,
> Glenn Reid
> Adobe Systems

How about the following:

/x [
    { a b c }
    { d e f }
    { g h i }
    { j k l }
  ] % Stack: /x array[4] 
  [ exch /exec /load load /forall load
    % Stack: /x --mark-- array[4] /exec --load-- --forall--
  ] cvx 
  % Stack: /x {array[4] /exec --load-- --forall--}
def

This is more-or-less equivalent to:

/x {
  { % executable arrays: low in calories, high on fiber!
    { a b c }
    { d e f }
    { g h i }
    { j k l }
  } /exec load forall % loads of fun for all!
} def

Except that the former also has the advantage of the '[' method 
Glenn describes for short procedures:

/x [
  { a b c } % gee, that's the only one; let's optimize:
  exch pop
def

PostScript is such a fun programming language! I just gets bad press
because some people have only looked at nasty optimized header files, 
and machine generated PostScript documents, expecting to be able to read 
them like Pascal programs! It really is a dynamic, powerful language! If 
you don't believe me, go read the Blue, Red, and Green PostScriptures! 
Then take a look at the source to Glenn's Distillery! /hashpath -- like 
wow, man! 

And as for the potentials of object oriented PostScript programming:
Just wait till you see the NDE toolkit kit!!

	-Don