🚀 go-pugleaf

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.

For example, consider "f(LIST p, LIST q), p notalias q".
Speaking Fortran, that means that the heads of the lists are not
aliased, but who knows about the rest?  One might, perhaps, say
something along the lines of either

  p(.cdr)* notalias q(.cdr)*  (default is aliased)
or
  p(.cdr)* mayalias q(.cdr)* (default is not-aliased)

to specify that the heads and the spines of the lists are not / may be
aliased.  (and what do I mean by not aliased?  For each run-time call,
taking the instersection of the two sets p(.cdr)* and q(.cdr)* should
yield the empty set, and mangle what I said to turn it into sets of
pointers to things.)

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'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