🚀 go-pugleaf

In article <940@helios.ee.lbl.gov> forrest@ux1.lbl.gov (Jon Forrest) writes:
}I'm a newcomer to Postscript and have been spending lots of time
}recently reading the standard Postscript material. One thing that
}has struck me is how hard it is to get used to a stack based
}language after being a Fortran and C programmer for so long.
}If I has been a Forth or HP calculator programmer I probably
}wouldn't have this problem.

  I don't think this is true.  Postfix languages are (IMHO) inherently hard
  to understand.  Problem is twofold:  (a) when it does things, you have NO
  way to know "why" (for's and if's, for example) and so it is hard to
  understand what the code is trying to do: so you have to read on, see what
  is supposedly happening, and then back up to reread what happened.  Which
  makes it more complicated than its rather simple repertoire of control
  structures would lead you to think; and (b) it is VERY hard to keep an
  intuitive grasp of what is happening on the stack.  This last is mostly a
  coding style question: many programmers are (these days) shying away from
  the cavalier use of side-effects because they make code harder to
  understand and more fragile.  Problem is that stack machines are ALL side
  effects: you call a function and you now have to REMEMBER how many stack
  things it eats, and how many it puts back, or else you're lost.   Again, it
  goes to making relatively simple operations _seem_ more complicated than
  they have to be and so harder to understand.  (and please, no "lessons"
  about RPN languages... I have a drawerfull of HP calculators and I've
  worked in APL and Forth.  I _can_ deal with postfix languages when I have
  to... I just don't LIKE them and I don't think they lead to _clear_
  solutions to problems.)

}What about a "compiler" that converts standard postscript into
}what I'll call infix/function form?

I think this'd be nice, but a serious problem is that stack machines are
inherently more powerful than "conventional" languages, and the simple parts
of postscript (converting "a b div" -> "a / b") aren't generally the places
where you run into trouble.  I think it'd be nice if you could do it,
but I fear it'd be hard (especiallyt o expect it to eat a bit of random
postscript and do anything helpful with it.. almost as bad a job to try to do
as the old "flow charters" fromthe old days that tried (unsuccessfully) to
make sense out of unrestricted assembly code).  If it is all full of dup's
and rolling the stack and doing large-scale tweaking of the stack, just to
fall into a single (magic) procedure call at the end (with by-then well
hidden args!), I think you'll be in trouble.

In my own postscript code, I've adopted various "defensive" techniques that
don't help me much with reading other folks's code, but at least make *my*
code pretty plain:

   a) when I enter a procedure, I "copy" the args into a bunch of local vbls.
     (generally with a string of "/varname exch def"s)
   b) I tend *NOT* to do long, involved stack manipulations.  Generally, I'll
      compute something and stuff it into a local, usually with a reasonable
      name, and then instead of seeing a "<whateverprocedure>" out in the
      middle of nowhere leaving the reader to guess what's on the stack, I'll
      have done:
	  <compute> /reasonabletemp exch def
	   ...
	  /reasoanbletemp /temp /.... <callprocedure>
      A bit of extra def'ing and stack'ing, but it makes the code MUCHO
      easier to understand.  When I'm DONE with the code and I know that it
      works, I can "encrypt" it to make everything be all stack-like.
    c) I avoide long "open coding" of {stuff} in if's and for's.  It is bad
       enough getting an intuition for what is going on to have
	   cur last <
	      drawtitle
	   if
       but having the boolean separated from the "if" by 25 lines of code
       that you don't know if you should be scanning or not is too much for
       me (ditto for the BOOL part: if it is more than some expression that
       is easily apprehended, I'll stick it in a temp)

Do you wizards have other tricks and stuff to make code more understandable
and *readable*, or is the emphasis always on getting things faster and more
compact?

   __
  /  )                              Bernie Cosell
 /--<  _  __  __   o _              BBN Sys & Tech, Cambridge, MA 02238
/___/_(<_/ (_/) )_(_(<_             cosell@bbn.com