Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!exodus!bendenweyr!flar
From: flar@bendenweyr.Eng.Sun.COM (Jim Graham)
Newsgroups: comp.lang.postscript
Subject: Re: A question about //add
Message-ID: <2724@exodus.Eng.Sun.COM>
Date: 14 Nov 90 02:23:53 GMT
References: <1990Nov12.195235.13908@light.uucp>
Sender: news@exodus.Eng.Sun.COM
Reply-To: flar@bendenweyr.Eng.Sun.COM (Jim Graham)
Organization: Sun Microsystems, Inc.
Lines: 66

Here are the relevant references as I see them:

From "UPDATE for the APPLE LASERWRITER and LASERWRITER PLUS - Revision 2":

	The language syntax has been extended to include a new kind of
	name token, the *immediately evaluated name*.  When the scanner
	encounters the token '//name' (a name preceded by two slashes
	with no intervening spaces), it immediately looks up the name in
	the context of the current dictionary stack and substitutes the
	corresponding value for the name.  If the name is not found, an
	*undefined* error occurs.

	The substitution occurs *immediately*, regardless of whether or
	not the token appears inside an executable array delimited by
	'{...}'.  Note that this process is a substitution and not an
	execution; that is, then name's value is not executed but rather
	is substituted for the name itself, just as if the *load* operator
	hand been applied to the name.

The important points are that the substitution is performed by the
scanner, not by the interpreter.  They qualify that no execution is
performed to clarify that building an array such as:

	{ 1 2 //add }

will not generate:

	{ 3 }

as the scanner only "looked up" the add operator, but did not "execute"
it.  The interpreter will execute the add operator when it encounters
it by executing that array.

In immediate mode, the scanner gives the add operator itself '--add--'
to the interpreter.  The interpreter then executes the add operator
as it does under any other circumstance.

From Section 3.2 - INTERPRETER - of the redbook:

	The PostScript interpreter is the process that executes the
	PostScript language according to the rules given in this chapter.

	...

	The interpreter operates by executing a sequence of objects.

	...

	The objects to be executed by the interpreter come from two
	principal sources.  First, objects previously stored in an
	array in PostScript memory may be executed in sequence.  Such
	an array is conventionally known as a *procedure*.  Second, a
	character stream may be scanned according to the syntax rules
	of the PostScript language, producing a sequence of new objects.
	As each object is scanned it is immediately executed.

This says that the PostScript interpreter treats objects that come from
the scanner just the same as it treats objects that come from a PostScript
array.  When the scanner scans a procedure {...}, that procedure goes on
the operand stack, just as it would if it were encountered while executing
an executable array.  When the scanner scans an operator object (possible
only by using the // syntax since there is no other syntax which can
produce an operator object), the interpreter executes it just as if it
had encountered that object in an executable array.

						...jim