Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!batcomputer!munnari.oz.au!comp.vuw.ac.nz!windy!srwmcln
From: srwmcln@windy.dsir.govt.nz
Newsgroups: comp.lang.postscript
Subject: Re: A question about //add
Message-ID: <18754.2742b042@windy.dsir.govt.nz>
Date: 15 Nov 90 15:12:02 GMT
References: <1990Nov12.195235.13908@light.uucp> <321@heaven.woodside.ca.us>
Organization: DSIR, Wellington, New Zealand
Lines: 39

In article <321@heaven.woodside.ca.us>, glenn@heaven.woodside.ca.us (Glenn Reid) writes:
> In article <1990Nov12.195235.13908@light.uucp> bvs@BitBlocks.COM (Bakul Shah) writes:
>>All versions of the (Adobe)  PostScript interpreter since version
>...... 
> 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.
>
My understanding of // should behave as above,
 1 2 --add-- in a procedure and 3 outside.

This does lead to the need for exec following //'s which are replaced by
procedures rather than operators. ie

/dd {......} def
{//dd exec} true if

On our LaserWriter IINT, from within (v47.0) executive:

1 2 //add pstack       produces 3.

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

Adobe implementations can only be taken as a guide to the correct semantics.

Clive.