🚀 go-pugleaf

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

I suppose I could have mentioned some of that in the Green Book, but I
didn't realize why I had done it that way until just now.  I had
devised the technique to solve a particular problem, and couldn't
remember why it was different than { {a b c} exec }.

But you still get ten extra points.  In fact, it pleases me to no end
that you understand the language well enough to have made this
intuitive leap yourself.  My biggest hope is/was to explain the
mechanism of the interpreter well enough that people will understand
the language and how to think like the interpreter, rather than looking
at /proc { ... } def as if it were Pascal.  You've made my day.  And
you don't need to read the rest of the Green Book :-)

Regards,
 Glenn Reid
 Adobe Systems