Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!spool.mu.edu!munnari.oz.au!metro!extro!rossc
From: rossc@extro.ucc.su.OZ.AU (Ross Cartlidge)
Newsgroups: comp.lang.postscript
Subject: Re: Bind is a travesty
Message-ID: <rossc.674175497@extro>
Date: 13 May 91 22:58:17 GMT
Article-I.D.: extro.rossc.674175497
References: <1991Apr29.073421.2622@neon.Stanford.EDU> <486@heaven.woodside.ca.us>
Sender: news@metro.ucc.su.OZ.AU
Organization: Sydney University Computing Service, Sydney, NSW, Australia
Lines: 55
Nntp-Posting-Host: extro.ucc.su.oz.au

glenn@heaven.woodside.ca.us (Glenn Reid) writes:
...
>> %   A bind problem is a case where the `bind' function is used
>> %   on `free' variables:
>> %
>> %      /test { x y add } bind def
>> %
>> %   may not work correctly if the document is included in an environment
>> %   where `x' is defined on the dictionary stack.

>If `x' is defined but is not an operator, "bind" leaves it alone, as it
>should.  In your example, only "add" would be affected by the "bind"
>operation, unless for some reason "x" or "y" was a name that pointed
>directly to an operator object.  What exactly is the problem?
	
	In my experience the "bind" problem is part of a larger
	problem in PostScript. It is the slightly different
	behaviour of Operators and Procedures.

	A few years ago I wrote a PostScript prolog called "multi.ps"
	which when prepended to ANY PostScript (not just EPSF) it
	put multiple pages on a page. It worked by overloading
	all the operators which affect the absolute graphics (like showpage
	and initgraphics, etc). My biggest problem was that it meant
	changing many operators into procedures. This broke arbitrary
	PostScript in (at least two) ways.

	1. bind used to break recusion.
	   EG
		/showpage { showpage (G'day) == } bind def
	   now generated an infinite loop

	2. procedures don't execute when pushed onto stack
	   EG
		/showpage { //showpage (G'day) == } def
	   will now push "showpage" onto the stack but not execute it.

	I realise the PostScript which causes the problem is a bit
	naughty, but lots of PostScript translators (TeX for one)
	do things like this. As for Apple's Laserprep - it does every 
	naughty thing in the book.

	But the problem remains that to fix 1. I have to
	overload bind with a rather messy function and
	I have no way of fixing 2. as // is a lexical operator-
	and ofcourse // is not the only way "operators" can be
	pushed onto the stack.

	If anyone has a solution to this I'll put it into
	multi.ps straight away.
-- 
________________________________________________________________________
Ross Rodney Cartlidge			    |   rossc@extro.ucc.su.oz.au
University Computing Service, H08	    |   Phone:     +61 2 6923497
University of Sydney, NSW 2006, Australia   |   FAX:       +61 2 6606557