Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!parcplace!aladdin!ghost
From: ghost@aladdin.com (L. Peter Deutsch)
Newsgroups: comp.lang.postscript
Subject: //add
Message-ID: <25.UUL1.3#5127@aladdin.com>
Date: 13 Nov 90 15:44:29 GMT
Organization: Aladdin Enterprises, Menlo Park, CA
Lines: 41

Here is my analysis of this issue:

As I read the Adobe literature, what I believe is supposed to happen
is that:

	When the scanner sees an occurrence of //name, it replaces this
	occurrence with the object that would be returned by executing
	/name load.

It is also clear that

	When the interpreter encounters an executable operator, it
	executes the operator.

(If it were otherwise, I believe the 'bind' operator couldn't work.)

If you agree with these readings, then it seems to me that the result
of executing (at the top level)
	1 2 //add
is unambiguously 3, since the scanner replaces the //add by the
executable 'add' operator, and what the interpreter sees is
	1 2 --add--
where --add-- is a mythical syntax for writing an executable operator.

Glenn Reid's example
	/proc { one two //add } def
	/one 1 def
	/two 2 def
	proc
also unambiguously produces 3, since it is equivalent to
	/proc { one two --add-- } def
	/one 1 def
	/two 2 def
	proc

I'm now pretty well convinced that this interpretation is correct,
and the QMS printer ROMs have a bug.

L. Peter Deutsch :: Aladdin Enterprises :: P.O. box 60264, Palo Alto, CA 94306
ghost@aladdin.com ; {uunet,sun,decwrl}!parcplace!aladdin!ghost ; (415)329-0264
	    "Implementation is the sincerest form of flattery."