British Computer Society Logo British Computer Society Fortran Specialist Group

 UK requirements mtg
- Programme
- Participation
- Factsheet
About Us
- FSG Home page
- Joining the Group
- Contact Details
- Important Disclaimer

Notes of meeting
"UK requirements for next revision of the Fortran language"

Held at 5 Southampton Street, London WC2E 7HA, on 10th March 2005.

Present:  Ian ChiversRhymney Consulting
Peter CrouchDepartment for Work and Pensions
Ian HounamNumerical Algorithms Group Limited
Jane SleightholmeKings College London
John YoungAtomic Weapons Establishment, Blacknest
Apologies:  David MuxworthyBSI Fortran Panel
Ben RalstonAtomic Weapons Establishment
John ReidJKR Associates

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:

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

Valid XHTML 1.0! 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.

  - Top of page © Copyright British Computer Society