Some more general remarks on F90 etc.

I have started wondering after responses to my earlier wishlist
which actually unknowingly duplicated proposals of others.
From some of the responses it must have become clear that
new features are wanted but only few will be added. Even
some very obvious ones are still not on the committee's
agenda.

Questions:
-Are any of the members on the j3 committee listening to our
 debate (with the exception of van snyder and m cohen, of course)?
 If not most of our discussions are useless.

-Is J3 actively seeking opinions on wanted features from users
 other than the main computer and compiler vendors?
 Is there feedback from classes learning Fortran, from
 Computer Science departments (if you like it or not, they
 set the fashion on computer languages, and Fortran is
 rather old-fashioned to them), from other science departments
 (physics, chemistry, engineering, etc)?

-Is there a broad agreed direction that Fortran should take?

-Some new features show problems. Is the committee willing to
 correct/change them to something better? If the F90 base is
 not very big yet this should not cause to many problems.
 Asking colleagues and friends most of them still don't use F90!
 They even don't know some of the most important features!


Some raised objections:
-Some of the wanted features exist in other languages (e.g., enum in C,C++)
 so that there should be little problem of implementing them.
-The example of extending case to real variables must be trivial
 any objection to it is -in my mind- more obstruction than anything
 else since it just regularizes what we already have with more
 complicated if-then-else structures.
-Initializing ADT's, inheritance (at least simple) is also
 done all over the place, so there shouldn't be any great difficulties.

I have some problems with modules, the issue of separating
interface and implementation is one and already discussed by others.
A second one is why this new feature was not introduced
with safety in mind, i.e. everything in a module is private
unless declared public.
This is a general problem and if the safety/robustness issue
is not incorporated from the beginning in any new Fortran feature
it will haunt us later again and again. Examples include
-ALLOCATED (F95 automatically deallocates)
-NULL for pointers (but there are still undefined pointers
 that cannot be tested)
-PRIVATE vs PUBLIC (see above)
-initialized ADT's (F95 has it)

In the many attributes I listed for Fortran I didn't mention
efficiency. Fortran has always claimed to be more efficient than
others but some C++ code seems to be coming closer (blitz++)
or an example for FFT's shows code with recursions to be very
fast (http://theory.lcs.mit.edu/~fftw/homepage.html).

Two points of view are possible:
  If this advantage of Fortran is lost or less obvious than the
  general power of a language to express what the user wants to
  do becomes more important. And Fortran is behind here (except
  for array notation).
Or
  Some features are actually not as bad as is generally claimed
  and with a little bit of discipline hardly any loss of speed
  is suffered. And Fortran loses one of its attractive features.
In any case Fortran has to improve.

There are sometimes objections to make some features oobsolete
since older code will become incompatible with any new Fortran.
F95 has done it already, the F and elf subsets even more.
F77 compilers will be around for some time, and is no one
maintaining code? A lot of old code is rewritten anyway
since the old codes are not suitable anymore (Or are undocumented
and no one knows anymore, so one have to rewrite)
Code is still is best document of itself and clarity of
code (and language) is worth a lot.
But people are of course very stubborn, I still alot of NEW code
using EISPACK/LINPACK routines instead of the better LAPACK
ones.

In my field of ab-initio quantum mechanical calculations most
of the speed gains come -at the moment- from improved theoretical
methods and less from computing features. Traditionally this has
all been done in Fortran and is still done. But in many cases
we need a more expressive language with modular features so that
it is easy to adapt to rather quickly changing times, more robustness
and safety.

F90 has done a lot in this direction and without it I would have
switched to C++ or something else some time ago. But I want and
need more. And other users feel the same.

WWS
-----------------------------------------------------------------------
| Werner W Schulz |
| Dept of Chemistry email: [log in to unmask] |
| University of Cambridge Phone: (+44) (0)1223 336 502 |
| Lensfield Road Secretary: 1223 336 338 |
| Cambridge CB2 1EW Fax: 1223 336 536 |
| United Kingdom WWW: |
-----------------------------------------------------------------------



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%