Path: utzoo!utgpu!watserv1!watmath!att!att!linac!uwm.edu!zaphod.mps.ohio-state.edu!rpi!uupsi!cmcl2!lanl!jlg
From: jlg@lanl.gov (Jim Giles)
Newsgroups: comp.lang.misc
Subject: Re: Answers, Chapter 1: TeX
Message-ID: <4869@lanl.gov>
Date: 3 Nov 90 01:48:27 GMT
References: <1990Nov2.183359.6761@maths.nott.ac.uk>
Organization: Los Alamos Natl Lab, Los Alamos, N.M.
Lines: 101

From article <1990Nov2.183359.6761@maths.nott.ac.uk>, by anw@maths.nott.ac.uk (Dr A. N. Walker):
> [...stuff that shows that _sombody_ finally understands what I'm saying...]
>
> 	The counter argument is that it puts the burden in the wrong
> place.  JLG is asking the *programmer* to assert something that may
> not be assertable.  Some of the procedures in the call chain may be
> library procedures, or may involve global variables from other modules,
> for example.  How do *I* know what aliassing may occur?  [...]

Exactly the problem I kept trying to point out to someone via private
email (and the reason I don't deal with that person over email any
more - he ignored the point and kept claiming that the compiler by
itself could do all).  It is for this reason that the loader is
required to do some work.  It _can_ do the call tree analysis (if the
compiler passes along all the information).  Any errors the loader
finds in this search correspond to aliasing that you didn't declare
(or possibly, aliasing that you _did_ declare unnecessarily).  This is
how you learn what aliasing may occur.  I maintain loaders in large
machine environments - so I'm reasonably sure that the loader is up to
the task provided the allowed aliasing is specified clearly enough.

> [...]                                                    Further,
> in languages which (very usefully) allow dynamic array slicing, the
> presence or absence of aliassing may often only be determinable at
> run time, so either I program "defensively" and declare the alias
> (so having a program which always runs slowly), or I take pot luck
> and have a program which may fail at run time.

Yes, this is a problem.  This is one reason that I insist on complete
information about arrays to be retained by the parameter passing
mechanism.  The compiler _can_ analyse _some_ of these occurrences
and give messages if you guessed wrong.  To be sure, there are some
cases where the compiler can't decide - and you can't either - so
you have to program defensively in those cases.  Fortunately, such
cases, while common, are not in the majority - the method I suggest
will allow significant and useful control for the programmer in
most cases

> [...]
> 	In fact, the *real* situation, is that if the compiler and
> loader can determine whether or not aliassing can occur, then the
> "alias" declaration is unnecessary, [...]

Well, true only if the loader is able to do code generation or the
compiler is able to do interprocedural analysis.  In existing
implementations, the information found by the loader is too late
to effect what code the compiler generates.  This is why the
declarations at compile time are necessary - the loader only
checks to make sure that your intended constraints are actually
met.  (Unfortunately, if they are not met, it is indeed the
user's problem to correct.  But the loader can at least give
full particulars about what didn't match-up.)

> [...]                               and if they can't, then a run-time
> check is needed anyway.  [...]

Or, defensive programming (and accepting the loss of efficiency)
is also possible here.  I don't know which to prefer.  The run-time
check is only required for those cases which the compiler/loader
combination couldn't fathom.  This may happen in a lot of important
cases, but this still leaves most cases working efficiently with
the scheme I propose.

> [...]                    Hints to compilers, if thought desirable,
> could be given in all sorts of other ways.

Yes, but this is the way I've chosen.  You can disagree with the syntax
or argue that it fails in some difficult to fathom case (like passing
the red and black squares of a chessboard as separate arguments), but
I will still claim that it's useful in many other important cases.
If you have an alternate mechanism to suggest, please feel free!
I'd like to see other people's ideas.

> [...]            On the other hand, if you have (say) a graph,
> and at some point in your program you discover a node with an
> interesting property, how *do* you naturally refer later to that
> same node *other than* by explicitly or implicitly keeping a
> pointer to that node?

By keeping an aliased variable of the same recursive type which
references that node.  Note, as I've repeatedly said, "aliased"
variables provide the _same_ functionality as Pascal pointers.
In fact, the compiler _should_ generate the same code (if not
better, since my suggestion limits aliasing more strictly).

> [...]                                         A finger by any other
> name is still a pointer.

Well, I will continue to stick to the definition of pointers that
I've posted.  Since my "aliased" variables are more restricted I
will continue not to call them pointers.  But, they allow the user
to implement the same structures (in the same way: if he aliases
everything) as Pascal pointers do.  For recursive data structures,
"aliased" variables work the same way Pascal pointers do, but the
class of objects each variable may be aliased to is much more
severely limited - that's the whole difference apart from minor
syntactic changes.

As for a finger being a pointer: only when I point with it.

J. Giles