Article View: comp.lang.postscript
Article #3659//add
From: L. Peter Deutsch
Date: Tue, 13 Nov 1990 15:44
Date: Tue, 13 Nov 1990 15:44
41 lines
1640 bytes
1640 bytes
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."
Technical Details
Message-ID:
<25.UUL1.3#5127@aladdin.com>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!parcplace!aladdin!ghostShow Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!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