🚀 go-pugleaf

In article <321@heaven.woodside.ca.us> glenn@heaven.woodside.ca.us (Glenn Reid) writes:
> ...
>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'.

The scanner _does_ return 1, 2 and then --add-- to the
interpreter.  So the effect is really as if the `load' operator
was applied by the *scanner*.  The real question was what does the
interpreter do when directly given --add-- (except for //, this
would never happen at the top level).

>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.

For // semantics *within* a proc, there are no discrepancies
between the Red Book, the language Supplement (file `language.ps'
from the Adobe File Server), my QMS printer and Ghostscript.  For
example, if the input has
	``{ one two //add }''
all of them say you get an executale array
	{ one two --add-- }
on the operand stack.  The scanner does exactly the same thing
with // in the deferred or immediate execution mode.

>	2) wait for the new red book to be published and hope that
>	   the semantics are made explicit, or

I hope the new red book will also clear up a number of other
imprecisions in the Red Book (like the definition of `=' on page
114 does not mention if a newline is appended), and define minimum
limits every implementation must obey.

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

And one I should have never stopped to think about :-)

-- Bakul Shah
  bvs@BitBlocks.COM
  ..!{ames,att,decwrl,pyramid,sun,uunet}!amdcad!light!bvs