Peter Crouch, FSG Chairman, welcomed everyone to the meeting. Despite the small attendance he was pleased to see representatives of users, compiler vendors and trainers.

In the absence of David Muxworthy and John Reid through ill health their presentations were taken as read. The Chairman recorded his thanks to David and John for providing their presentations and wished them a speedy return to good health.

UK Requirements for Fortran 2003+

The six proposals circulated before the meeting were discussed.

1. Pointer function references as actual arguments
2. Pointer function references as lhs in assignment
   The meeting supported the above two proposals, subject to editorial tidying up as proposed by Malcolm Cohen.
   
   
3. Multiple Nonzero-Rank Part References
   This proposal was also supported but see MC's comments made by e-mail after the meeting.
   
   
4. The ADDRESS attribute
   The main comment was "can't this be done already?". Also see MC's comments made by e-mail after the meeting.
   
   
5. TYPEDEF facility
   The meeting felt this would be a nice facility to have but not a vital one. However see MC's comments made by e-mail after the meeting.
   
   
6. Long integer data type
   The meeting supported this proposal. However see MC's comments made by e-mail after the meeting.

The meeting went on to consider the four UK proposals listed in DM's presentation.

• UK-001 Co-array Fortran for parallel programming
  The meeting strongly supported this proposal. See also the revised proposal circulated after the meeting.
  
  
• UK-002 Decimal floating point arithmetic
  UK-003 Conformance to IEEE 754R
  These two proposals appeared very similar and would be of benefit for financial applications. The main comment was "how did the the timescale for the development of IEEE 745R fit with the timescale for Fortran 2003+?"
  
  
• UK-004 KIND environment specification
  There was discussion of what the KIND values should represent. Were they just arbitary values showing how many KIND values were available for each intrinsic type or should they give the size of each KIND available, in bits or bytes? The meeting supported the principle that KIND values should be standardised.

As there was still plenty of time available the meeting looked at the J3 Submissions listed in DM's presentation.

The meeting supported most of the items listed and made the following comments:

• J3-029 More info on GET_COMMAND[_ARGUMENT] failure
  This should be extended to GET_ENVIRONMENT_VARIABLE.
  
  
• J3-002 GET_IO_UNIT
  This would be a very useful facility.
  
  
• J3-009 IO_UNIT standard derived type
  Ian Hounam suggested that MC be asked to give his opinion of the usefulness of this proposal and how easy would it be to impliment.
  
  
• J3-003 EXECUTE_COMMAND_LINE
  This would be a very useful facility and should be given higher priority.
  
  
• J3-004 STORAGE_SIZE
  J3-006 Find logical and character KINDs
  J3-030 Selection of most common real and integer kinds
  The meeting strongly supported the proposed inclusion of named KIND constants in ISO_FORTRAN_ENV. These proposals look very similar to or are closely related to proposal UK-004 and should be given a higher priority than suggested by J3.
  
  
• J3-007 CONSTRUCT Name Local to CONSTRUCT
  The meeting did not support this proposal.

Of the items listed in J3's classification of "low priority" items the meeting wished the following submissions to be given a higher priority:

• Execute External program intrinsic (J3-003)
  Simplified KIND selection (J3-030)
  Compiler Version [char constant in ISO_FORTRAN_ENV]
  
  
• The meeting did not support the "Use, Not ..." proposal.

Comments provided by e-mail:

John Reid, 08/03/05
I am trying as a UK Fortran programmer to influence the UK position.

My first point is that I think we are being rushed. It seems inappropriate to choose the features for a revision of Fortran 2003 before any compilers are in place and before we have any experience of using the language. The counter argument is that the features for Fortran 2003 were chosen a long ago and we need now to consider those features for which a need has became apparent since that time.

So I would like us to be very mean about the features that we approve in Delft for inclusion. Let me remind you of our scale (N1594):

1. Minor editorial (less than 10 lines altered).
   
   
2. Significant editorial (up to a page altered) with no technical change.
   
   
3. Very minor technical change. An example is adding the optional argument KIND to IACHAR (see 1.12 in N1509). Also major editorial (up to a chapter altered) with no technical change.
   
   
4. Minor technical change. An example is changing type-bound generics to be sets of specific named type-bound procedures (see TC4 in N1506).
   
   
5. Technical change likely to need more than two J3 meetings to develop. An example is reallocation of allocatable arrays (see TC11 in N1506).
   
   
6. Technical change likely to need more than a year to develop. The modules and allocatable TRs are examples.
   
   
7. Technical change likely to need more than 2 years to develop. The IEEE TR is an example.
   
   
8. Technical change likely to need more than 3 years to develop. Interfacing with C and the OO features are examples.

It is probably a good idea to approve soon any at level 6 and above (e.g. Co-array Fortran or parameterized modules, see J3-05-145r3) so that J3 has plenty of time to work on them, but let's leave room for smaller proposals later.

Malcolm Cohen, 18/03/05
Actually, I think that in Delft we should decide as much as we can. (I don't mean to decide to do as much as we can...) Whether a feature is big or small, if we know we want it, we should decide to do it.

We should at least pick a little more than J3 has time to finish before the next meeting. Otherwise we end up defaulting the decision on what to do to J3. I've not been hugely impressed by J3's procedures for decision-making this time around.

Furthermore, we have to pick ALL the big items we intend to do. Next meeting will be too late since by definition they will then take longer to develop than the time available.

One question for the UK is surely whether to push co-array Fortran since we brought the subject up.

For that matter, how many big items do we want to do? Do we want to do ANY big items?

Perhaps we should discuss all the repository entries prior to the meeting; I know everyone is busy (I sure am) but having been flooded by J3 suggestions leaving it until the meeting will be too late. We should at least form an initial opinion on some of them beforehand, even if we change our minds at the meeting.

Any Other Business

In the autumn of 2004 a note was published in the Computer Conservation Society's "Computer Resurrection" suggesting that 2004 was the 50th anniversary of the birth of Fortran. The FSG Chairman with assistance from David Muxworthy wrote to the Editor of "Resurrection" suggesting that while 2004 could be considered as the 50th anniverary of the conception of Fortran the 50th anniversary of its birth would be in early 2007. For various reasons the next issue of "Resurrection" which should contain this letter had not yet appeared. (It was finally distributed towards the end of April.)

It was agreed the the Chairman and John Young should liaise with the CCS regarding a celebration of the 50th anniversary of the launch of Fortran in 1957, to be held in early 2007.

The Chairman closed the meeting by thanking everyone for their time and contributions. The agreed notes from the meeting would be passed on to the BSI Fortran panel to assist them in preparing the UK's submission to the WG5/J3 meeting in Delft in May this year.

Peter Crouch
March 24, 2005

Comments on this or any other of the Group's pages should be sent by e-mail to the BCS FSG Web Editor, Peter Crouch.