🚀 go-pugleaf

Woody Baker @ Eagle Signal writes
> In article <JWZ.91May6183906@thalidomide.lucid.com>, jwz@lucid.com (Jamie  
Zawinski) writes:
> > 
> > > I think the problem is using insanely short identifier names.  This isn't
> > >       /p /show load def
> > 
> > You shouldn't be "picking weird names to try and survive."  You should be
> > picking meaningful identifiers because it's good programming style in any
> > language.
>  I have to agree with this in part.  For a compiled language, it does not
>  matter, as the variables are reduced to memory locations at compile or link
>  time, but for interpreters, it does matter.  Lookups take time.  The
>  scheme that Adobe uses, is fast, but still takes time.

Name lookup is not affected by the length of the identifier name.  Only
scanning (or transmission time).

> In general, in an interpreter type language, the most frequently used
> variables should be as short as possible name wise, and the less frequently
> used variables should be longer.  This does make a certain amount of sense,

Jamie's post was correct, although not many people seemed to read it
carefully.

There are two kinds of uses for identifiers (roughly speaking):

   A. those that are used only within procedures in the prologue, as
      variable names and as names for procedure names called from
      other procedures in the prologue.

   B. those used in the body of the document, to invoke procedures from
      the prologue.

Identifiers in the "B" category should be short, because they're
transmitted often.

Identifiers in the "A" category should be long and readable, because they
are only read ONCE (or a few times, at most) by the scanner, as it is
digesting the prologue.  Here's a short example, using a long name for a
procedure that is only called from within the prologue, and a short name
for an often-transmitted procedure call:

/lock_coordinates {
    transform round exch round exch itransform
} bind def

/L {
    lock_coordinates moveto
    lock_coordinates lineto
    stroke
} bind def
%%EndProlog

100 300 500 700 L

--
 Glenn Reid				RightBrain Software
 glenn@heaven.woodside.ca.us		NeXT/PostScript developers
 ..{adobe,next}!heaven!glenn		415-326-2974 (NeXTfax 326-2977)