🚀 go-pugleaf

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