🚀 go-pugleaf

Jeff M Younker (jeff@uh.edu) wrote:
: Brian Rogoff wrote:
: > How about the ability to create new value types? Not necessarily
: > low-level, as Ada 95, Eiffel, and Sather allow this, yet prevent
: > the pointer madness of C and C++ (please, there is no language
: > "C/C++"). Who needs this? Anyone who needs fast, compact arrays
: > of user defined elements.  This means anyone who needs to write
: > numerical methods, signal processing, and certain fast graphics
: > algorithms in the language.
: > ...
: > We are already seeing the complaints on this newsgroup :-)

: Value types are really cool from a conceptual point of view, but
: I am not so sure that they are necessary to achieve fast numerical
: code.  If my understanding is correct, Fortran 77 (the premiere
: language of high speed code) treats integers, floats and complex
: numbers as references.  I have yet to hear anyone complain about
: the speed of Fortran code.  From this I would conclude that what
: really matters is the quality of the compiler, not the
: semantics of the language.

This is not true.  Fortran scalars and array elements are not shared
references. 

For instance if I say

          I = 2
          J = I
          I = 3

then "J" is not '3', it is still 2.  This is not so important for
scalars like this, but it is critical if you want to believe that
A(I+J) is distinct from A(J+K) if I+J .ne. J+K.

In a purely reference language *all* elements of an array could point to
the same underlying storage location.  This completely kills optimization. 

This is not possible in Fortran.  

(Yes there is "EQUIVALENCE" which is a grody hack but still not reference
 semanatics, but the language then warns people to use it at their own risk
 and does the standard optimization assuming unshared anyway.)

What Fortran does have is argument passing to subroutines by
reference for scalars.  This is not as consequential. 


: - Jeff Younker - jeff@uh.edu - These are my views, not those of UH -