🚀 go-pugleaf

In article <3859@exodus.Eng.Sun.COM>, chased@rbbb.Eng.Sun.COM (David Chase) writes:
|> mccalpin@perelandra.cms.udel.edu (John D. McCalpin) writes:
|> >> wgh@ubbpc.UUCP (William G. Hutchison) said:
|> >> I see at least two solutions:
|> >>  (1) Stop doing numerical work [ :-) ]
|> >>  (2) Find or develop a language suitable for this sort of work.
|> >...
|> >My interests right now are leaning more toward Modula-3, because of
|> >its support for classes/objects.
|> 
|> Unfortunately, Modula-3 fails in the same way that C does with respect
|> to (pulling out a quote that you didn't quote):
|> 
|> >> (2) C programmers mostly work on micros, workstations, or minicomputers,
|> >>     so they are not acquainted with pipelining, vectorizing, parallel
|> >>     processing, etc., so they do not know what they are missing by using C.
|> 
|> These optimizations apply about equally well (poorly) to C and
|> Modula-3.  The reason, barring whole-program optimization (interesting
|> in a land of pointers-to-procedures, too) is that Fortran has its
|> weird little parameters-are-not-aliased rule, and C and Modula-3 do
|> not.  It's a little easier to mandate not-aliased in a language
|> without recursive data structures (i.e., pointers) like Fortran; in
|> C/Modula-3/others, such a rule seems oddly stunted and special-case.
|>
|> [example of passing two lists] 

I agree with your observation that Modula-3 can yield the same aliasing
problems as C, and with your additional point that it is not enough
to declare that the top level objects are not aliased.  

However, I disagree with the implication that having recursive data
structures implies having pointers.  Hermes has recursive data structures
but does not have pointers.  Variable sized collections of things
can be declared as "table of <type>" or as "ordered table of <type>".
Additionally, a type (typically a table or a variant) may contain components of
the same type.  (For example type "S-expression" may contain a variant case
type "pair" whose components are of type "S-expression".)

From the programmer's point of view, every variable holds a separate
copy of the data and there is no aliasing.  However, the compiler and runtime
environment are free to optimize the performance of operations which copy or compare
"large" objects by letting equal data objects share storage.  So there
may be aliasing going on "under the covers" which the user doesn't see. 
However, in these cases the compiler also takes the responsibility to ensure that
a true copy is made before any attempt is made to modify a shared copy.
This is the language-level analogue of "copy-on-write".
The "optimization" is beneficial only if the savings in copying/comparing
outweigh the costs of any run-time checks for aliasing.
 
|> Anyhow, perhaps this explains why these rules have not been adopted in
|> other languages (yet).  All the solutions I come up with in a couple
|> of minutes appear weird, ad hoc, and non-general.  Non-aliasing
|> mandates have good effect on remote implementations of things (RPC),
|> too, which is another reason to like them even if you hate heavy-duty
|> optimizations.
|> 

I agree that if pointers are explicit, the problem is harder because
the programmer is generating the aliasing, but the compiler has to detect it
(or provide a way for the programmer to indicate potential aliasing).
This is harder then either the case where the programmer is responsible
for both generation and detection or the case where the compiler is
responsible for both.
 
|> I'd have to go read more about this stuff to get a handle on what is
|> good, bad, and ugly -- unless the FX-87 people want to get into a
|> discussion about their work (much of which remains unread by me,
|> unfortunately).  It helps to keep the constraints of checking and
|> inference in mind, also -- closure properties of regular languages
|> are very useful, for instance.
|> 
|> David

-- 
Rob Strom, strom@ibm.com, (914) 784-7641
IBM Research, 30 Saw Mill River Road, P.O. Box 704, Yorktown Heights, NY  10958