🚀 go-pugleaf

Rob Bradlee writes
> Is the cleartomark a legitimate way to make sure you've left the stack in  
good
> shape or a cheap trick that absolves you from the effort of thinking?

I think it's a cheap trick, myself :-)

The only justified use of it is if you include arbitrary PostScript
that you do not know or trust (as in an EPS file). If you wrote the
code, you should clean up after yourself.  If you write things
properly, there shouldn't be anything on the stack anyway when you
get to the "cleartomark".

If you really aren't sure what's on the stack, how do you know there
isn't another "mark" (equivalent to a "[", by the way) on the stack
somewhere?

Anyway, I'd avoid using it if I were you.

One of the things that I sometimes do with particularly gnarly bits
of code is to force an error where your "cleartomark" is and see the
contents of the stack, count them, analyze them, then look back at
the code to get rid of anything that shouldn't be there.  For example,
people often use "stringwidth" but forget to pop the unused "Y" value,
and it's still sitting there later.

Just my $.02

--
 Glenn Reid        		NeXTmail: glenn@rightbrain.com
 RightBrain Software		415-326-2974 (NeXTfax 326-2977)
 Palo Alto, California

bradlee@cg-atla.UUCP (Rob Bradlee) writes:
>/utility_procedure {
>	mark
...stuff...
>	{
>	% test was true.  Process the rest of the items on the stack.
>	}
>	{
>	% test failed. cleanup.
>	cleartomark
>	}  ifelse
>} def

>Is the cleartomark a legitimate way to make sure you've left the stack in good
>shape or a cheap trick that absolves you from the effort of thinking?

Glenn Reid took the "cheap trick" position, which I think is true most of
the time.  However, if testing and processing arguments, managing inter-
mediate results, etc., gets complex enough, I think the mark...cleartomark
is cleaner and clearer than a proc which ends something like:
		} {
			pop pop
		} ifelse
		pop
	} {
		exch pop pop
	} ifelse
...as you try to dig your way back and balance the stack at the end.  This
is hardest in a proc which is coping with error situations and trying to
invoke error handlers with the right stack context.
-- 
Dick Dunn    rcd@raven.eklektix.com   -or-   raven!rcd    Boulder, Colorado
				Cats!