Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!cs.utexas.edu!ico!rcd From: rcd@ico.isc.com (Dick Dunn) Newsgroups: comp.lang.postscript Subject: Compiled PostScript Summary: simplistic assumptions Message-ID: <1989Dec28.000745.6265@ico.isc.com> Date: 28 Dec 89 00:07:45 GMT References: <28@macuni.mqcc.mq.oz> <17490@rpp386.cactus.org> Distribution: comp Organization: Interactive Systems Corporation, Boulder, CO Lines: 28 woody@rpp386.cactus.org (Woodrow Baker) writes: > Actually, a Compiled version of PS is not unreasonable. Given a good > BNF of the language, YACC and LEX should make the parser a snap. The BNF of PostScript is so trivial it's (a) uninteresting and (b) unhelpful. The parser is a snap; it would be kinda dumb to use YACC for it. (Of *course* the parser is simple--that's one of the arguments for using a postfix stack-oriented language!) What you'll find if you really look at compiling PostScript (assuming you know about compilation) is that you aren't likely to gain much. All the good stuff happens in the operators. Given dynamic binding (which begets latent types as well), things are inexorably pushed off to run time. You can find lots of special cases, and make up a slew of special rules, and make a little headway. (For example, something common like "3 1 roll" can be generated inline since the operands are constants, if you know or make a rule that "roll" can't be redefined and can deduce that you won't get a stack underflow...) You might speed up typical processing by a few percent, no more, because the work all happens in the operators. But this is all old stuff to people who know about language implementation (including, apparently, the Adobe folk who designed the language). Lan- guages intended for interpretive execution are characteristically syntax- poor and operator-rich...and compiling them seldom gives you much. -- Dick Dunn rcd@ico.isc.com uucp: {ncar,nbires}!ico!rcd (303)449-2870 ...Mr. Natural says, "Use the right tool for the job."