Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!elroy.jpl.nasa.gov!decwrl!adobe!heaven!glenn
From: glenn@heaven.woodside.ca.us (Glenn Reid)
Newsgroups: comp.lang.postscript
Subject: Re: A question about //add
Message-ID: <321@heaven.woodside.ca.us>
Date: 13 Nov 90 03:43:38 GMT
References: <1990Nov12.195235.13908@light.uucp>
Reply-To: glenn@heaven.woodside.ca.us (Glenn Reid)
Organization: RightBrain Software, Woodside, CA
Lines: 86

In article <1990Nov12.195235.13908@light.uucp> bvs@BitBlocks.COM (Bakul Shah) writes:
>All versions of the (Adobe)  PostScript interpreter since version
>25.0 provide an immediately evaluated name facility:  When the
>scanner encounters a `//name' token, it immediately looks up the
>name in the current dictionary stack and substitutes the name's
>value for the name[%].  The effect is as if the `load' operator
>had been applied to the name (except that this happens in the
>scanner).
>
>Now the Question.  If at the top level (i.e. not nested within
>any braces) the input is
>	1 2 //add
>should the operand stack contain
>	1 2 --add--
>or
>	3
>? You can test this by feeding
>	1 2 //add pstack clear
>to your PostScript interprter.
>
>My QMS PS 410 printer (running Adobe PostScript version 52.4) says
>the stack has 1 2 --add--.  Initially I thought that was the
>correct behavior but L.  Peter Deutsch <ghost@aladdin.com>, the
>author of Ghostscript, argues the stack should contain 3 and I
>agree with him now.

Just as a data point, I tried your program on my (Adobe) Display
PostScript interpreter and got "3" on the stack:

	heaven> /usr/lib/NextStep/WindowServer -e start
	PostScript(r) Version 1006.24
	PS>1 2 //add pstack     
	3 
	PS>quit

I happen to believe that it should leave "1 2 --add--" on the stack,
since there are situations in which executing the "add" operator could
lead to errors, such as the following:

	/proc {
	    one two //add
	} def
	/one 1 def
	/two 2 def
	proc

This actually wouldn't work right with either semantics.  You would
need an "exec" after the "//add" in one case, and you'd get an
"undefined" error on the name "one" in the other case :-)

And, as long as we're nitpicking....

>                           The effect is as if the `load' operator
>had been applied to the name (except that this happens in the
>scanner).

If the effect is *really* as if the `load' operator had been applied,
then you should get "1 2 --add--" in your example.  The real question
hinges on whether the semantics of // are equivalent to `load' or to
the automatic name lookup mechanism.  I prefer the semantics of `load'.

This is further complicated by the fact that // should probably do
different things depending on whether or not it is in deferred execution
mode (inside curly braces).  I would suggest that inside a procedure
body // should produce "1 2 --add--", even if you convince me that
it should produce "3" outside a procedure body.

Now that we have two examples of Adobe implementations that implement
each of the two choices in semantics for your example, we can do one
of three things:

	1) assume that the most recent implementation represents
	   the truth,
	2) wait for the new red book to be published and hope that
	   the semantics are made explicit, or
	3) wait for someone from Adobe to pipe up.

You have posed a most interesting question, and one that I have never
stopped to think about.

% Glenn

-- 
 Glenn Reid				RightBrain Software
 glenn@heaven.woodside.ca.us		PostScript/NeXT developers
 ..{adobe,next}!heaven!glenn		415-851-1785