General Remarks:

    These are some wishes that I see as useful from my own programming
    experience. Of course, not everybody will agree with this rather
    personal list of wishes. I am ignorant about other proposals
    for F2000. Maybe I am duplicating here. Maybe some things
    are too difficult to implement and there are reasons why it
    might be dangerous.

    In any upcoming new standard for Fortran any suggested additions
    should be checked whether they enforce or at least encourage these
    points:
      -safety
      -reliability
      -transparency
      -portability
      -avoiding redundancy
      -compatibility with F77 if it is shown not to clash
       with the above
      -new powerful abstractions, esp object-oriented facilities

     F2000, F90, F95, F77 are the common abbreviations.

Features on my wishlist:

(o) Status of pointers/allocatable arrays:
    Pointers should be either associated or disassociated.
    Dangling pointers should be caught by the system.

(o) Pointers:
    allow pointers to have user-set indices:
        A(0:20) => A_Target(20:40)
    or A( :20) => A_Target(20:40)
    or A(0: ) => A_Target(20:40)
    Pointers (at least the aliasing pointers) are for the
    convenience of the user, this should be enhanced as much
    as possible

(o) Pointers to real/imaginary part of complex numbers
    There is definitely a need to be able to address the
    real and imaginary parts of complex numbers with pointers.
    In practice the F77 way of using code is like this

       Complex AB(100)
       ...
       CALL DOIT( AB )
       ...
       SUBROUTINE DOIT( AB )
       Real AB(*) ! This is now 2*100 Reals with
                             ! Order Re(1),Im(1),Re(2),Im(2),...
       ...
       END

    This is not very transparent, but a necessity if one wants
    to treat real and imaginary part separately. Just take a look
    at FFTs to see why (save on operations).
    In F2000 I would like to see something like

      Complex, TARGET :: C(100)
      Real, POINTER :: R(:), I(:)
      ...
      R => REAL( C )
      I => AIMAG( C )

      or other ways of directly addressing the two components
      as one can do with user-defined types.

(o) The usefulness of RESHAPE and PACK is that it moves the
    burden of indexing from the user to the compiler. This would
    further enhanced by allowing a pointer to point to such a
    structure:
        Real, TARGET :: T(:)
        Real, POINTER :: P(:,:)
        P => RESHAPE( T, (/N,M/) )

   In practice this is done very often in F77 by passing an array
   into a subroutine where the array is declared with different
   rank.
   The pointer arrangement would be more transparent and safer.

(o) enumerated Type:
    Ada, C/C++, etc have it. It is a very useful and concise way
    to set up a list of options etc.
    It is always better to refer to options/constants by name
    rather than by number as frequently done in old F77 codes
    In F90 one cannot easily collect these options/constants into
    one structure.
    Example:
       TYPE(Enum) :: Weekdays(0:6) = (/Sun,Mon,Tue,Wed,Thu,Fri,Sat/)
    Now one use either Weekdays or directly Sun, etc.


(o) OO Features:
    The introduction of user-defined types (ADTs)
    has been a great step forward for Fortran but currently any
    addition to a type involves the cumbersome introduction of
    subtypes, just try to translate the 'standard' examples
    of person --> student --> graduate student into Fortran90.

    A good OO implementation should be implemented asap.
    There are some good and not so good OO languages out there
    (Eiffel, Beta, Python, etc) and one should learn from them
    what to do and what to avoid.
    There is also some danger that Fortran becomes slowly obsolete
    as fewer and fewer people learn it since it has the notion of
    an old-fashioned language.
    Of course, there will be traditionalists that will 'object' to
    this, but there are so many cases where it is useful, so why
    wait any longer?

(o) Shortening of Fortran
    I think there are many instances where the style of programming
    could be enhanced by allowing more concise statements,
    e.g. ALLOCATE( X(1:N)=Zero ) allocates an array X(1:N) and sets
    all elements to Zero.
    The parameter list of Subroutines and Functions could have
    the declarations of their arguments directly there:
    SUBROUTINE SUB( Integer, INTENT(IN) :: A &
,Real, INTENT(IN OUT) :: B &
                  )
    instead of repeating it again. It is also less error prone
    (though most compilers will pick it up).


(o) ASCII characters:
    It is about time to allow for a truly international use of characters.
    The latin-1 (better the unicode ISO 10646) should be mandated asap.
    The old ICHAR,CHAR intrinsics should become obsolete. There is no need
    to support two different character sequences for only historical reasons.

    I hear that something along these lines is being proposed already.

(o) Extension of CASE:
    The current version of the CASE statement is a somewhat inconsistent
    with the rest of the language. It is a much needed improvement of
    the IF-block but has been defined, im my opinion, in the wrong way.

    A more useful form is:
    SELECT CASE( A )
           CASE( r1<=A<r2, r3<A<=r4, r5,r6,r7 ) ! r stands for range
               ...
           CASE( r2<=A<r3, r8,r9 )
               ...
           CASE DEFAULT
    END SELECT
    where A can be integer or real or character(ASCII).

    The CASE construct is closer to IF-blocks than array indexing
    and this should be reflected.
    In addition, the range expressions should be allowed in IF
    statements as well. (FORTRAN=FORmula TRANslation, remember?)
    I.e. IF( Zero<=X<Two ) THEN
    instead of
         IF( Zero<=X .AND. X<Two ) THEN

(o) EXITs:
    allow exits from any block structure not just DO loops
    this would make goto even rarer.
    But do not ban GOTO's and CONTINUE completely, they are useful
    in -admittedly- rare cases.

(o) Modules:
    Though the Fortran Standard Committees do not like to get involved
    in matters of operating systems etc. there is a need to solve the
    MODULE problem: different compilers use different ways of providing
    the interfaces of modules during compilation (files .mod, .kmo, .o)
    This can make the porting of code utilities (makefiles) across
    platforms difficult.
    Secondly, there is the compilation cascade when the implementation
    of a module is changed but not its (public) interface.
    These matters leave room for improvements that have to be addressed
    soon.

    In addition, does the current standard say anything about this:
    Modules A, B, C
    B: use A
    C: use B ! is A also visible in C through B?


(o) Libraries:
    The step to include a string type (ISO_VARYING_STRING) is a good
    step and should used more often. Common data structures (such as
    linked lists, trees, heaps, etc) could be provided to reduce
    duplication of code, enhance safety, etc. or, at least provide
    us with model implementations that can be copied.


(o) Obsolete Features:
    - specific intrinsics and all the restrictions that come with them
             Do we really need ABS,IABS,DABS,CABS, ...
             (use generics)
    - Proposal: change AIMAG to IMAG to be consistent
    - DOUBLE PRECISION (use Real(kind=...))

    - PRINT (use WRITE)
    - NULLIFY (With the NULL in F95 NULLIFY becomes redundant.)

    - Restrictions on internal files (free format,namelist)
      This is really an annoying restriction. Anyone who has tried
      a tiny bit of text processing in Fortran will agree. Often, to be
      conforming with the language, one has to use SCRATCH files
      instead.

(o) Continuation Lines
    Why is it necessary to have an extra ampersand (&) in front of
    formatting statements in READ/WRITE calls?
    E.g. my DEC compilers complains about
    Write(I_OUT, '( " some Variable",I4 &
/" another one ",I4 &
                  )') I,J
    and wants
    Write(I_OUT, '( " some Variable",I4 &
& /" another one ",I4 &
                  & )') I,J
    I don't like to have two rules for continuation lines. Just disallow
    to break strings into two lines without quotes around them.
    Secondly why not allow an & either at the end or the beginning of line
    to indicate that is a continuation.

(o) IMPLICIT NONE
    It would have been a good idea to make this the default
    setting for F90 code in recommended format (i.e. free format)
    True it makes F77 and F90/95 a little bit imcompatible
    but safety should take priority.

(o) SAVE
    For the sake of transparency, variables should be saved between
    function calls only if they are declared with the attribute SAVE
    not just when initialized.
    This is, however, in conflict with the earlier standards.

(o) PARAMETER Variant:
    I have wished many times to have a variable that can only be
    declared once at the beginning of a programme and remains constant
    throughout.
    (setting options is a typical example)

(o) Overloaded Operators
    allow commutative operators to reduce duplication of coding
    Also, allow to declare some operators invalid for ADTs. There
    are times when I don't want an assignment of the intrinsic kind.

(o) Access to OS
    there should be some simple and STANDARD form of accessing the
    operating system and results from those operations
    CALL OP_SYS( ... )

(o) bindings to other languages
    I hear they are woorking on C <--> Fortran

(o) private/public Types
    Are there still compilers (e.g IBM's xlf, Hitachi's f90) around
    that have problems with type declaration of the code below.
    Just try the following example with f90 -c and see whether
    your compiler complains about the TraceList TL being private
    I am not sure what the F90 standard has to say about this but
    common sense tells me that Module B cannot redeclare the definition
    of the TYPE TraceList, that can be done only by Module Tracing.
    However, any variable declared in B can be private, but not
    dummy arguments in the parameter list of subroutines/functions.
    If necessary the standard should be reformulated.

    MODULE Tracing
       TYPE TraceList
            Integer :: Depth_of_Calls
       END TYPE TraceList
    END MODULE Tracing

    MODULE B
      USE Tracing
      PRIVATE
      PUBLIC :: Sub_B
      ! If there is a problem, try to use the next Line instead
      ! PUBLIC :: Sub_B, TraceList

    CONTAINS

      SUBROUTINE Sub_B( TL )
          Type( TraceList), INTENT(IN OUT) :: TL

          ! Entering Subroutine
          TL%Depth_of_Calls = TL%Depth_of_Calls +1

          ! .. ! do something

          ! Leaving Subroutine
          TL%Depth_of_Calls = TL%Depth_of_Calls -1
      END SUBROUTINE Sub_B

    END MODULE B


I hope this will stimulate some discussion about the
next Fortran version (if it's not too late) and
hopefully will include some of my wishes.

WS
-----------------------------------------------------------------------
| 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: |
-----------------------------------------------------------------------




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