🚀 go-pugleaf

rothman@tegra.com (Steve Rothman) writes:
>carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick) writes:
[example stuff]
>>	/BIG
>>	{ /POINTSIZE 18 def
>>	} def
>>	/SMALL
>>	{ /POINTSIZE 9 def
>>	} def
...[mixed uses of BIG and SMALL]...
>>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...

Yes, a PostScript interpreter can deal with this...but the output isn't
something you're going to like!  If you expand down to this level--which is
really a peephole into the execution loop--you get far too much detail.
Even very simple (seeming) sequences turn into thousands of operations...
"trust me" (sic), I've been there.  The level of detail it gives you is
useful for debugging an interpreter--*IF* the bug is a tough one and you're
persistent--but for general work it's just too much.  You get a beetle's-eye
view of part of one tree; the forest is but a curious rumor.

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

Yes, but in the case of substantial #defines that, too, is more than you
want to cope with.  Sometime, try the expansion of something as simple as:
	while ((c=getchar())!=EOF)
		putchar(c);
Even stdio is horrendous on a lot of implementations...and the expansions
don't tell you nearly as much about "what's going on" as you'd like; it's
more "how it's done".  moreover...

>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? 

No, there's no preprocessing to be done, unless you think of the effect of
"bind".

(I don't really want to sound as discouraging as I am; I'm just trying to
point out some avenues of inquiry that don't seem likely to pan out.)
-- 
Dick Dunn    rcd@raven.eklektix.com   -or-   raven!rcd    Boulder, Colorado
	...Simpler is better.