Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!natinst!rpp386!woody From: woody@rpp386.cactus.org (Woodrow Baker) Newsgroups: comp.lang.postscript Subject: Re: Compiled PostScript Summary: amen Message-ID: <17503@rpp386.cactus.org> Date: 28 Dec 89 17:25:32 GMT References: <28@macuni.mqcc.mq.oz> <1989Dec28.000745.6265@ico.isc.com> Distribution: comp Organization: River Parishes Programming, Plano, TX Lines: 33 In article <1989Dec28.000745.6265@ico.isc.com>, rcd@ico.isc.com (Dick Dunn) writes: > 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. Amen. Being that we are dealing with a language that is not a context-free grammer, It does not make much sense to compile it. The language is idealy suited to interpretation. . > 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."