Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!decwrl!adobe!heaven!heaven.woodside.ca.us
From: glenn@heaven.woodside.ca.us (Glenn Reid)
Newsgroups: comp.lang.postscript
Subject: Re: Bind problems
Message-ID: <488@heaven.woodside.ca.us>
Date: 5 May 91 17:36:30 GMT
References: <1991May5.010114.24826@neon.Stanford.EDU>
Sender: glenn@heaven.woodside.ca.us
Lines: 36

Tomas G. Rokicki writes
> Bind cuases problems if a document that includes a definition such as
> 
>    /p /show load def
> 
> then includes a graphic file that does something along the lines of
> 
>    /test { /p exch def p show } bind def
> 
> for a simple example.  I have found that this happens fairly often.

Hmmm.  So the problem is really a name collision between an outer and
an inner program that use the same variable name.

Maybe it's not "bind" that's at fault, but for people (like me) to
recommend using "load" to tie an operator directly to a user name.
Perhaps you shouldn't do that unless you're quite sure the name is
likely to be unique.

If the original document had used

     /p { show } bind def

There would be no problem.  "bind" actually helps in this case, and
although there's procedure call overhead, it's almost as fast as

     /p /show load def

It's not just "free variables" that cause the problem.  It's limited
to names that are bound directly to operators, which can only be
accomplished using the "load" operator.  I'd place the blame there.

--
 Glenn Reid				RightBrain Software
 glenn@heaven.woodside.ca.us		NeXT/PostScript developers
 ..{adobe,next}!heaven!glenn		415-326-2974 (NeXTfax 326-2977)