From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
Newsgroups: comp.lang.postscript
Subject: Re: PostScript disassembler?
Date: 10 Nov 92 23:24:33 GMT
Article-I.D.: gap.1dpgbiINNnss
Reply-To: carl@SOL1.GPS.CALTECH.EDU
Distribution: world
Organization: HST Wide Field/Planetary Camera
NNTP-Posting-Host: sol1.gps.caltech.edu

In article <BxIEBK.BC1@tegra.com>, rothman@tegra.com (Steve Rothman) writes:
=In article <1dmj7eINNha9@gap.caltech.edu> carl@SOL1.GPS.CALTECH.EDU (Carl J
=Lydick) writes:
=>Sorry.  Can't be done.  Consider the following (legal) Postscript code:
=>
=>	/BIG
=>	{ /POINTSIZE 18 def
=>	} def
=>	/SMALL
=>	{ /POINTSIZE 9 def
=>	} def
=>	BIG
=>	/Courier findfont POINTSIZE scalefont setfont
=>	72 72 moveto
=>	(This is the big font) show
=>	SMALL
=>	/Courier findfont POINTSIZE scalefont setfont
=>	72 144 moveto
=>	(This is the small font) show
=>	showpage
=>
=>Now, how would your "disassembler" expand POINTSIZE?
=
=Well, I guess I would want it to replace POINTSIZE with 18 in the first
=instance and 9 in the second. Somehow, a PostScript interpreter can deal with
=this.  Maybe you mean to say that the program I'm looking for is just as
=complex as the parsing machinery used by a PS interpreter (which is way beyond
=me). But "can't be done" seems a little strong... 

Can't be done IN A DISASSEMBLER.  What you're asking for is a PostScript
INTERPRETER with a trace capability.  Of course, there's no way of telling a
priori whether or not the output of this interpreter will be finite for any
given postscript file :-).

=By the way, maybe a better analogy to what I want (rather than "dissasembler")
=is a C preprocessor that can take a C program, with all kinds of #defines,
=#includes, and various conditionals, and turn in into straight C code.

No, that's *STILL* a bad analogy.  If you apply the C preprocessor to a finite
C program, the result is guaranteed to be finite.  Not so in your mythical
disassembler.  It's easy to write a PostScript program that never stops.  You
need a PostScript interpreter, not a "disassembler."

=This kind of utility I think is always included with C compilers, probably
=because it's a step that is done automatically during normal compilation
=anyway.  Perhaps "preprocessing" is also a step that PS interpreters also have
=to do anyway. In that case, might not a PS interpreter allow this as an
=option?

I believe they do the evaluations on the fly, rather than generating the HUGE
amounts of code that would be required if they tried to "preprocess" things
then execute them.  Yes, an interpreter *COULD* be written which has a trace
capability.  But it would not, in any reasonable sense of the word, be either a
"disassembler" or a "preprocessor."
--------------------------------------------------------------------------------
Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL

Disclaimer:  Hey, I understand VAXen and VMS.  That's what I get paid for.  My
understanding of astronomy is purely at the amateur level (or below).  So
unless what I'm saying is directly related to VAX/VMS, don't hold me or my
organization responsible for it.  If it IS related to VAX/VMS, you can try to
hold me responsible for it, but my organization had nothing to do with it.