Dear All,

I've recently re-read Van Snyder's report 97-114 of the Fortran 
J3 working group. Instead of quoting this >80 page document, 
I'll just give two pointers:
  ftp://ftp.ncsa.uiuc.edu/x3j3/doc/meeting/140/pre/
  ftp://ftp.dfrc.nasa.gov/pub/x3j3/ncsa/doc/meeting/140post/
with all files
  97-114*.ps.gz
I'd like to comment on some of the features that are on my private 
wish list. I will not repeat suggestions which I endorse, but have 
nothing to add.

3. Intrinsics
3.1. Linear Algebra

V.S. suggests to add MaxAbsLoc, MinAbsLoc etc. numerical intrinsics.

I'd add a few more, including F90 versions of some of BLAS 1 and 
perhaps simplest BLAS 2 routines. Someone might point out that 
this is an issue of standardizing a library, but I specifically put 
it in the intrinsics sections for the following reasons:
a) the procedures should be known to the compiler, so that all 
   optimizations are possible,
b) they should be elemental and generic with respect to argument 
   type (integer, real), kind and where possible dimensions, which 
   is more than BLAS offers,
c) they should have a decent F90 interface (one name, array 
   descriptions passed implicitly),
d) avoid unnecessary copying of pointers (which happens in some 
   compilers).

F90 is a language for numerical analysts, engineers etc. (I don't 
believe in general purpose formal languages) and BLAS 1 (with 
extensions) is arguably the most widely accepted scientific library 
in existence. It is already implemented by many vendors of Fortran 
and thus it's inclusion in future Fortran releases should not be 
a problem.


10. Control structure extensions / regularizations

I'd be happy to see a BLOCK construct proposed by V.S.

10.3. Extensions / regularizations for CASE
10.3.3. Real CASE ranges

This subject is widely discussed in the group (thread: wish list of 
fortran features). I'll not repeat all that.

I essentially agree with V.S. except one (admittedly minor) point. 
V.S. suggests that COMPLEX expressions should not be allowed in 
CASE constructs because there's no ordering of complex numbers. 

There's no *strict* ordering that everyone would agree upon, however 
a *weak* ordering exists when you treat complex numbers as 2D vectors. 
Then, of course there exit numbers for which none of the ==, >=, >, 
<= and < makes sense. 

Example: 

COMPLEX :: c

SELECT CASE( c )
CASE( COMPLEX(-1,-1) <= * <= COMPLEX(1,1) )
  ! ....
CASE( COMPLEX(1,1) < * <= COMPLEX(5,5) )
  ! ....
CASE DEFAULT
  ! ....
END CASE

Allowing the above *when* *no* *overlapping* *occurs* would (I think) 
be more regular than making an exception. Naturally, it would require 
definition of comparison operators for complex numbers according to 
the weak ordering rules.


19. Very local variables

I find them useful in C++. They make existence of BLOCK construct 
an obvious asset. They also benefit from allowing to mix executable 
code with declarations. An effect similar to mixing can be obtained 
in F90 when we allow implicit declarations, but I am more likely 
to vote for a ban on implicit declarations than endorse them.

A number of arguments for very local variables may be listed
a) better code readability / maintainability when a variable is 
   declared just before it's first use and not at the top of 
   the procedure,
b) easier code updates with guaranteed local effects, exluded 
   name clashes etc. (important both during development and 
   maintenance),
b) improved error detection when a variable which went out of its 
   very local scope is no longer visible (same benefits as with 
   disallowing implicit declarations),
c) may help optimization because the compiler is told when 
   a variable is no longer needed.

Yes, I've heard the story of a good optimizing compiler that does 
not need the extra information. Apparently the good compiler got 
eaten by the wolf.


20. Is FPP or COCO necessary?

I do believe in the merits of preprocessing. I currently use 
a C-style preprocessor on my F90 code (courtesy of SUN Workshop, 
which does it for me). The feature I find most useful is 
conditional compilation depending on existence or lack of 
a defined symbol (#ifdef/#endif construct).

V.S. proposes to allow standard F90 'IF' and 'SELECT CASE' 
constructs with conditions constant at compile time (PARAMETERS) 
to be placed nearly everywhere in the bodies of the procedures,
and outside.

What V.S. proposes looks very nice to me but I'd add at least 
one minor comment:
  The standard should *require* that conditional compilation 
  V.S. style produces *no* run-time code for the parts excluded 
  by the c.c. statements.

Probably the biggest problem with the proposal would be totally 
improper nesting.


21. A SWAP operator would be useful

Indeed it would. Somehow very few languages implement this obvious 
operator.


22. Enumeration types

V.S. proposes to allow
  ENUMERATION COLOR (RED, GREEN, BLUE)
(there's also another syntax, but I like this more as it seems 
cleaner when you need to enumerate, say, 20 objects).

C++ has a rather nice enumeration. It's a kind of a well tested, 
useful, easy to implement feature that might be easily incorporated 
in Fortran for everyone to enjoy. C++ allows
a) just to define the symbolic names and compare them for equality 
   (a commonsense restriction not enforced by the compiler) or
b) define the names and give them specific integer values (then it 
   makes sense to allow all integer operations to be performed).

Case (a) is generally useful when we have a set of symbols to which 
we do not wish to assign any meaningful numbers. Case (b) is useful 
when we want a symbolic (and thus humanely readable) representation 
of some numbers that are given to us. Perhaps it would be advisable 
to make a semantic and syntactic distinction between the two cases 
and allow only assigmnent and comparisons ==, /= in case (a) and 
full integer interaction in case (b).

There's one important benefit of enumerations that I rarely see 
mentioned. If you have an enumeration (esp. of type (a) above) 
you are likely to use it at some point in your code in a SELECT 
CASE statement. The compiler might check whether all enumerated 
values are mentioned and issue a warning when that's not true.

This is especially helpful when you add some new values to an 
existing enumeration and then try to update the rest of the code 
to reflect the changes.


23. Module interfaces and implementations should be separated

YES. I wrote it before on many occasions. Lack of separation 
creates many nightmares; one not mentioned in V.S.'s report 
comes to my mind.

If one uses access protection (PUBLIC/PRIVATE) attributes it 
is now necessary to put all procedures that are to have access 
to module's PRIVATE 'parts' in the module. And that may easily 
result in 50 KB or 100 KB of code in one file. Do I have to say 
why I don't like it?

And even without access protection separation is much too 
cumbersome: you have to put derived types in one module, 
procedure interfaces in another and then place the procedures 
as you like. That requires at least two files for the interface 
instead of comonsense (and proposed by V.S.) one.


24. Modules need initialization parts

V.S. gives all the right reasons. I'd extend the initialization 
notion much further.

It's not just modules that need initialization. So do derived 
types, arrays of intrinsic types and simple intrinsic type 
objects. To avoid clashes with existing software and aid 
optimization:
a) make initialization of intrinsic type objects and arrays 
   optional with default as it is now (i.e., no initialization),
b) allow additional attribute INIT in data object delcarations,
c) allow creation of INITIALIZERs for derived data types.

An INITIALIZER should be almost the same as a subroutine with 
(at least) the following exceptions:
a) takes only one INTENT(OUT) argument of the derived type which 
   it is supposed to initialize,
b) has no name or it's name is identical to the name 
   of the type or is the type name with some pre- or postfix,
c) cannot be called explicitly (more than just as if it was 
   PRIVATE to the module),
d) is called implicitly when an object of the type with INIT 
   attribute is created (e.g., as an automatic variable),
e) perhaps more restrictions to make it, e.g., callable in 
   parallel.

My general idea is to implement the simplest version of C++ 
constructor. More general ideas might be even better, but 
the above seems useful to me as it is.

Then destructors come to mind. With OO some form of this will 
become very necessary.


25. Fortran could have referential invariance
25.3. Make the array section selector a first class type

V.S. proposes to make regular array section selectors a type 
with some simple inquiry, update and comparison rules.

For reasons mostly unrelated to 'referential invariance' I'd 
gladly extend that to also having irregular array sections 
(vector indices) as another first class type.

My reasons are mostly readability and (possible) optimizations. 
Here comes an excerpt from my actual sparse matrix code 
(as it might have been if I hadn't rewritten it to DO loops):

      LoopOnColumns: DO j=1, K%n
         ! Unpack the j-th column of 'A' into 'wa'
         wa( A%col(A%row_start(j):A%row_start(j+1)-1) ) = &
            A%a(A%row_start(j):A%row_start(j+1)-1)

         LoopOnEntries: DO i=1, K%n
            val = DOT_PRODUCT( &
               A%a(A%row_start(i), A%row_start(i+1)-1) , &
               D(A%col(A%row_start(i), A%row_start(i+1)-1)) * &
               wa(A%col(A%row_start(i), A%row_start(i+1)-1) )

            ! And so it goes ...
         END DO LoopOnEntries

         ! Clean up the 'wa' work vector
         wa( A%col(A%row_start(j):A%row_start(j+1)-1) ) = 0
      END DO LoopOnColumns

Now imagine that with (irregular) sections:

      SECTION(IRREGULAR) :: col1, col2, row1, row2

      LoopOnColumns: DO j=1, K%n
         ! Unpack the j-th column of 'A' into 'wa'
         row1 = A%row_start(j):A%row_start(j+1)-1
         col1 = A%col(row1)
         wa(col1) = A%a(row1)

         LoopOnEntries: DO i=1, K%n
            row2 = A%row_start(i), A%row_start(i+1)-1
            col2 = A%col(row2)
            val = DOT_PRODUCT( A%a(row2), D(col2) * wa(col2) )

            ! And so it goes on and on ...
         END DO LoopOnEntries

         ! Clean up the 'wa' work vector
         wa(col) = 0
      END DO LoopOnColumns

Isn't the benefit self-evident?

OK. That's it for my comments.


Since the post is rather long I suggest responding to one issue at 
a time. And I definitely suggest responding.

My best regards,
----------------------------------------------------------------------
Artur Swietanowski                mailto:[log in to unmask]
Institut fuer Statistik,  Operations Research und Computerverfahren,
Universitaet Wien,  Universitaetsstr. 5,  A-1010 Wien,  Austria
tel. +43 (1) 407 63 55 - 120      fax  +43 (1) 406 41 59
----------------------------------------------------------------------


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