Xref: utzoo comp.windows.news:1276 comp.lang.postscript:1967 comp.lang.forth:877
Path: utzoo!dptcdc!jarvis.csri.toronto.edu!mailrus!ncar!tank!mimsy!brillig.umd.edu!don
From: don@brillig.umd.edu (Don Hopkins)
Newsgroups: comp.windows.news,comp.lang.postscript,comp.lang.forth
Subject: Beyond PostScript
Summary: Gratuitous PostScript extensions, anyone?
Keywords: PostScript, Forth, PIX
Message-ID: <16993@mimsy.UUCP>
Date: 19 Apr 89 04:50:00 GMT
Sender: nobody@mimsy.UUCP
Reply-To: don@brillig.umd.edu.UUCP (Don Hopkins)
Organization: U of Maryland, Dept. of Computer Science, Human Computer Interaction Lab
Lines: 57

What if there was another bit in every PostScript array reference
(like the executable bit), that when set, makes it an "inline
executable array", i.e. when the interpreter hits an inline executable
array, it would execute it (push it directly onto the execution stack)
instead of pushing it onto the operand stack. Then autobind could
replace names that were bound to inline executable arrays, as well as
built-in operators like it does now... So you could define your own
autobound inline PostScript functions, which didn't have to be looked
up on the dict stack at run time! (You could accomplish the same thing
manually by pushing the array and then doing an exec, ala {//myfunc
exec}, but that's twice as many runs through the interpreter loop.)
Inline executable arrays could save a lot of dictionary searches,
especially when used for the non-primative functions in systemdict
(the last dict in the search list, and quite a whopper), and commonly
called functions in userdict.

That's the funny thing about PostScript ... The interpreter treats
arrays differently than everything else: When it comes across an
executable array in a function, it pushes the array onto the operand
stack, same as with literal arrays.  I think it could speed things up
a bit if you could have a kind of super-executable array that was
automatically executed, that the scanner automatically autobinds into
your functions.

Something Forth has that PostScript doesn't is the notion of
"immediacy". (This is something different than "inline executable
arrays" described above.) Each Forth word has a bit that tells if it's
immediate or not (most aren't). The compiler (i.e. scanner, in the
case of a hypothetically extended PostScript) *executes* an immediate
word (function) instead of compiling it (i.e. putting it into an
executable array). It would be like an extended mode of autobind.
Immediate functions take care of compiling (or scanning) themselves.
They can even read things off the input stream following the token
that invoked them.  This mechanism is used in Forth for implementing
control structures, macros, inline string literals, and other types of
magic compiler constructs.  The way the NeWS scanner works would have
to be changed to accomodate immediate PostScript function, because the
scanner uses its own special stack for building executable arrays.
You'd want the PostScript scanner to put a mark on the operand stack,
and push each array element as it's scanned. When it scans an
executable token that's bound to an immediate function on the dict
stack, it would execute that function, then go on scanning the rest
of the array.  Immediate PostScript functions would be able to look at
the operand stack to see what of the array has been scanned so far,
and anything they left on the stack would end up in the array.

User definable magic variables and tuple-space operations (ala PIX)
could be a great deal of fun, too! [Check out Wm Leler's "PIX, the
latest NeWS" in the Proceedings of COMPCON Spring '89, IEEE, and N.
Carriero and D. Gelernter's "Linda In Context", in the April 1989
CACM.]
 
But then it wouldn't be PostScript TM, would it?  (Ah, yes, the
eternal tension between featurization and standardization. Phooey.
Onward!)

	-Don