🚀 go-pugleaf

In article <Bx7oAz.7Lp@mentor.cc.purdue.edu>, hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
|> [...]
|> Now a knife, or a gun, can be used for good or evil.  They can cause
|> accidents.  Likewise with pointers.

Yes, but pointers should be available for *voluntary use* - not 
by compulsion.  They are *not* adequate substitutes for arrays.
Explicit pointers are *not* needed for dynamic memory allocation.
I would prefer *not* to have to use them for simply connected
recursive data structures (like acyclic lists or trees).

Pointers are the GO TO of data structuring.  They are used to create
spaghetti data structures in the same way GO TO is used to create
spaghetti code.  If it's at all possible to avoid using them, don't
use them.  As with GO TO, you only use 'em when you GOT TO.  Also,
as with GO TO, there are ways to make your use more structured if
you *must* use them.

   First: in both, you should avoid having loops.  In the case of GO TO,
   you should try not to branch backward.  In the case of pointers, you 
   should try to avoid cyclic data structures.

   Second: in both, you should avoid aliasing.  In the case of GO TO,
   you should avoid branching to the same label for many disparate
   reasons.  In the case of pointers, you should try to avoid have
   two pointers to the same thing *at all*.

   Third: you should avoid non-local references.  In the case of GOTO,
   you should not branch from one program unit to another (even if you
   *know* the target is all statically allocated or that it's still on
   the active call stack, etc.).  In the case of pointers, you should 
   avoid pointing at separately generated data - like from one global
   array to a different one or from one complicated structure to
   another.

These are not hard-and-fast rules, but guidlines.  However, with both
pointers and GO TO, you'll find it *mostly* both possible and desirable
to avoid them entirely, and to stick to these guidelines when you *do*
have to use them.  For both, there exist alternative structures in
many languages which replace (or hide - depending on how you look at
it) the most common uses of GOTOs/pointers.  It is even possible to
find corresponding structures for flow- and data-structuring:

      for/do loops   <=>   arrays
         Both of these apply to a fixed number of elements
         with predefined boundaries and strides.

      while loops    <=>   acyclic lists
         Both of these apply sequentially through an unknown
         number of elements until an unambiguous end condition
         is met.

      if/elseif/else <=>   trees (simply connected)
         Both are acyclic and branching (possibly with differing
         numbers of branches below each node).

      function call  <=>   directed graphs
         Both have an "overlapping tree" kind of structure.  The
         descendents of distinct nodes may be the same.  A cyclic
         graph is analogous to recursion in functions.

      etc..

In the domain of flow control, most people seem to intuitively use
the simplist structure for the job they have in mind.  They seem
to easily avoid unnecessarily using structures that are harder to 
debug than necessary.  In data structuring though, people often 
seem to deliberately allow cycles or aliasing: even when they 
aren't required for the problem.  This often leads to errors,
and such errors are usually among the hardest to identify and
correct.

Note: the above correspondance is not intended as a suggestion
of pragmatic connections: you don't always step through trees
with IF statements, for example.  It is a similarity of the
characteristics of the abstractions I'm pointing out.  (Though
you do indeed use DO loops for arrays and WHILE loops for
lists *most* of the time.)

-- 
J. Giles