The primary function of the meeting was the completion of the draft revised standard document for Fortran 2000 to the CD stage ready to be taken to SC22 for its public review processing. Most of the time was spent in technical subgroups examining papers with suggested editorial changes to the document. I joined the DATA subgroup because that was the area in the past I had been most involved with. Most of the edits were correcting typos or fixing description errors where the existing text was perceived as not adequately expressing the intent of the committee.

A number of technical changes were also discussed and to a somewhat disturbing extent for this late stage in the process a significant number were in fact implemented. However, the majority of the technical changes appeared to be relatively desirable. In the main they could be implemented with reasonably small changes to the document and in most cases they resulted in a simpler language but with enhanced utility (at least in my opinion).

The most significant technical change to my mind was the relaxation of some of the restrictions on initialisation expressions. It was overwhelmingly agreed by a straw vote of the full WG5 committee that any of the standard intrinsic functions could be used in initialisation expressions. The vendor representatives on the whole all opposed this change but those members representing users were all in favour. On J3 this left a majority still in favour, albeit a narrow one. As it stands now in Fortran 2000 it will be legal to write code such as:

REAL :: pi=4.0*ATAN(1.0), E=EXP(1.0)

Previously, real functions such as ATAN(), EXP(), LOG(), etc. were not permitted in such a context. The argument given by the vendors that allowing these meant that they would have to have the intrinsic mathematical functions library available at compile time and this was in some way difficult. Alternatively, they might have a different library available at compile time than would be used at run time (cross compilation for example) and hence could get values that could be different because of the possibly different round-off properties of these two libraries. Given that compilers exist that already provide this facility as an extension and that these are by no means complicated or large, I was not sympathetic to the vendor view.

A number of other technical changes were related to a feeling by a majority of the committee that some of the complexity of description resulted in a number of places where attributes of entities could be inferred by the processor from the way in which the entity was used (c.f. old fashioned implicit declaration). A number of these were identified and after consideration simplified (in my opinion) by changes that require explicit declaration by the user. The major one of these was the requirement that type-parameters of a derived type be explicitly declared. For example, a typical parameterised type would be defined by code such as:

TYPE MATRIX(K,M)
  INTEGER,KIND :: K
  INTEGER,NONKIND :: M
  REAL(KIND=K) :: ELEMENT(M,M)
ENDTYPE MATRIX

The type parameters are treated like dummy components and as with components they must be fully declared. At present type-parameters can only be integer but in the future they may be extended to be of other types.

Fortran 2000 permits type bound procedures. Such procedures can be accessed as if the procedure was a component of an object of the type, e.g.

A%PROC( <arguments> )

Where A is an object of a type that contains a type bound procedure with the name proc . The procedure will be defined in the normal manner with a collection of dummy arguments. Normally these will include at least one, probably the first, argument that is of the binding type to which the selecting object A will be passed. This situation is now defined as the default. Any other situation must be explicitly declared. That is, if for some reason the selecting object is not to be passed to the first argument the procedure must be declared as NOPASS in the binding.

An attempt had been made to make the acquisition of the EXTERNAL attribute by a procedure possible implicitly. This had not been successful. It added greatly to the complexity of the language description and had led to a possible incompatibility with Fortran 95. The language was changed so that a procedure now needs to be declared to be external for it to gain the EXTERNAL attribute.

Two other minor changes were made in the restrictions on source form. The maximum length of a name was raised from 31 to 63 characters and the maximum number of continuation lines in a statement was increased from 99 to 255.

There were a few changes also to the C binding features. I did not fully understand these and generally voted undecided on these extensions. I will not attempt to describe them here.

A further draft of the proposed TR (Technical Report) on module enhancements was presented. This is an extension to allow just the interfaces for module procedures to be declared in the usable module and to have the bodies defined in a SUBMODULE. This extension is highly desirable but was accepted too late to be included in Fortran 2000 as such; hence the use of the TR mechanism to obtain early implementation. The aim of this proposal is to enable a change to be made to the implementation of such a procedure but since the interface does not have to be recompiled it limits the compilation cascade that is now caused by such changes. Some important straw votes were taken giving direction to the project editor the effect of which it is thought will allow the TR to be finalised before the end of the year. The effect of the votes is that it should be possible to write a module,

MODULE PARENT
  INTERFACE
    MODULE FUNCTION FUN(A,B)
      REAL :: A,B
      COMPLEX :: FUN
    END FUNCTION FUN
END MODULE PARENT

SUBMODULE(PARENT) CHILD
  FUNCTION FUN(A,B)
    REAL :: A,B
    COMPLEX :: FUN
!...body of code implementing function
  END FUNCTION FUN
END SUBMODULE CHILD

The prefix MODULE on the function statement in the interface definition indicates that this interface body is not that of an external procedure but of a module procedure that is to be defined elsewhere in the same module or in one of its child submodules. The submodule program unit that is introduced by this TR must name its parent module so as to gain access to the data environment of its parent. The proposal also allows but does not require the interface information to be repeated. This is important if large modules/submodules are being produced. The module designer, who may well be different from the procedure implementer, will both have full access to the interface code where they need it but the processor will be able to check that the two versions of the interface are the same.

It is clear that the changes to the language at this revision are indeed major. It is also evident that as described in the current document they are distinctly "Baroque". It is not clear to what extent this is a feature of the language design as such or merely a defect in the description. In spite of this and the very large number of edits still being done to the draft, it was felt that the point had been reached where the proposed revision should be subjected to wider public scrutiny.