Minutes of BCS Fortran Specialist Group Meeting held at
BCS HQ on 19 January 1989
Present: Graham Barber - EPCL
Martin Counihan - Southampton University
E Golton - RAL
Anne Gooding - Air Products plc
Dave Griffiths - SSF
Valerie Harmer - University of Surrey
Bob Hatfield - Nottingham University
Les Hatton - Programming Research Ltd
Carol Hewlett - LSE
Peter Holland - SSL
Chris Lazou - ULCC
Clive Massey - Bath University
David Muxworthy - University of Edinburgh
Mike Nunn - CCTA
Shahzad Rahban - Queen Mary College
Les Russell - AWE
John Stratford - Queen Mary College
Paul White - Met Office
John Wilson - Leicester University
John Young - PE-MOD
l. APOLOGIES FOR ABSENCE
Apologies for absence were received from Mike Geary, Lawrie
Schonfelder, Mike Gunn, and Miles Ellis.
2. MINUTES OF THE PREVIOUS MEETING [6 October 1988]
On item 2 the National Information Software Service (NISS)
does not look at compilers but only acts as an information
providing service.
On page 4 the ISO Observer at X3J3 was Gerhard Schmitt not
Schmidt.
3. MATTERS ARISING
Fortran Compilers on PC's.
The Secretary, John Young, reported that Mike Gunn had
acquired the NCC's list of certified compilers. Mike Gunn has
also written to companies who advertise Fortran compilers for
PC's and, so far, has received only two replies. With the
current interest it was felt that this response was
disappointing. John Young said that due to other commitments he
was unable to support Mike Gunn on this sub-group but would still
act as a "clearing-house" for any information. An appeal was
made for another member of the Group to assist Mike Gunn and
Carol Hewlett said that she would be available to help.
The IUSC and CHEST evaluation of Fortran compilers was under
way and the Chairman, John Wilson, had received a mail message
from Laurie Burbridge of Bristol University. John Wilson and
Lawrie Schonfelder were included in the CHEST list of interested
parties and there had been a meeting in December 1988.
ISO Observer at X3J3.
The Group's support of Gerhard Schmitt's attendance at the
X3J3 in Boston has been acknowledged by letters of thanks from
Gerhard Schmitt himself, his superior, and Jeanne Martin the
Chair of WG5. Reports suggest that Gerhard Schmitt's presence
in Boston did influence the successful outcome of the X3J3
meeting even though he did not give a formal presentation.
Boston Meeting November 1988.
In the absence of the X3J3 representative, Miles Ellis, the
Chairman, John Wilson, led a discussion on the X3J3 meeting in
Boston based on the report from John Reid (Appendix B [of the previous
minutes]) and Brian Meek's article in Datalink dated 9 January 1989.
John Wilson read extracts from the article and these are summarised as
follows:
1. Internal Procedures.
WG5 removed this facility due to US pressure but X3J3
wanted it restored. Unlikely to cause any
disagreement.
2. Vector Subscripts.
Again WG5 removed this facility to satisfy US comments
so its restoration by X3J3 would not cause any
disagreement.
3. DO n TIMES
X3J3 voted for a DO .... WHILE facility but not a major
issue for WG5.
4. Parameterized KIND=LOGICAL
X3J3 wanted to exclude this statement but WG5 felt it
had to be included. Possible area of conflict here.
5. Stream I/O
X3J3 have done little work on this subject but WG5
strongly urged it to be included. No real disagreement
here but possible delay while details are worked out.
6. Pointers
X3J3 wanted unbounded pointers which provide more
flexibility but would require more work. WG5 wanted
bounded pointers which are relatively simple to define.
There followed a general discussion on these points within
the Group.
BSI Fortran Panel.
The Chairman of the Panel, David Muxworthy, had been delayed
by fog so again John Wilson led a discussion of the meeting held
on 9 January 1989. The Fortran Panel met to discuss a WG5
Informal Ballot which contained 9 questions concerning a
country's response to the new Fortran 88 proposals. The Group
discussed the questions and answers on the Ballot and felt that
the replies, in general, reflected the feelings of the Group.
John Wilson was unhappy about the questionnaire but the Group
felt that the items should be accepted with reservation. The
Vice Chairman, Chris Lazou, proposed that the Ballot be endorsed
as a positive statement of the British view of Fortran 88.
David Muxworthy arrived in time for the afternoon session
so the meeting continued with this item before he presented his
talk. He again went through the WG5 questionnaire and clarified
some of the points raised earlier. It was reported that the
Alvey/Salford University Group would test fragments of Fortran
from the S8 draft and that the IST5 Programming Languages Panels
which included Fortran were to be re-structured. The BSI Panel
had also discussed whether the NCC should provide a validation
suite of programs for Fortran 88. David Muxworthy said that the
Informal Letter Ballot stressed that there should be no more
delays. The Panel was also recommending accepting Bounded
Pointers rather than Unbounded.
David Muxworthy then drew the Group's attention to the fact
that the VALUES= statement on a READ statement had been voted
out by X3J3 but apparently had not been reported. It had also
been proposed to remove BOZ from KIND= for LOGICAL and that
Stream I/O would be a minimal set of functions. Chris Lazou
again stated that he thought the Panel had been very positive and
that the new standard Fortran 88 should be published as soon as
possible.
Martin Counihan asked where he could obtain SC22 papers such
as those listed in Appendix B top of page 4. John Wilson replied
that he thought they should be obtained through Jeanne Martin,
the Chair of WG5, or perhaps through members of WG5. He added
that WG5 Working Papers were not published and were not
available.
There followed a short discussion on Significant Blanks in
the Free Source Form.
[A report on the subsequent X3J3 meeting is in Appendix A.]
5. EXTRA MEETINGS ON FORTRAN
Fortran 88 Seminar - East Kilbride
Since the last meeting of the Group, the Glasgow branch of
the BCS has arranged and held a one-day seminar at the National
Engineering Laboratory. The speakers from the Group were David
Muxworthy and Lawrie Schonfelder and the seminar was organised
by John Bruce, Glasgow Branch's Public Relations Officer. John
Bruce reports that "the event was a great success with an
attendance of 110. NEL staff comprised more than half as 44 were
from Universities and Industry". John Bruce said that David
Muxworthy and Lawrie Schonfelder spoke with authority and
presented Fortran 88 in a positive way.
It was suggested at the Seminar that a sub-group of the
Fortran Specialist Group be set up taking in all four Scottish
Branches of the BCS. Monthly meetings would rotate around
Dundee, Edinburgh and Glasgow. There would be a
Secretary/Organiser of the sub-group which would operate under
the main Group. The frequency and format of the meetings had yet
to be decided.
The meeting endorsed the actions of the Glasgow Branch and,
in particular, John Bruce, who was commended for his work on the
Seminar. It was unanimously agreed that every support should be
given to this new sub-group and, if necessary, the Group would
seek extra funds from BCS to finance any extra costs. Initially,
it was felt that there was sufficient funds to meet any demands
from the new sub-group and that any request made could be met.
Evening_and Tutorial Meetings
The Vice Chairman, Chris Lazou apologised to the Group for
not being able to arrange an evening meeting on Fortran in
London. The Group gave the go-ahead to anybody who wished to
organise an evening meeting or a tutorial meeting to do so. It
was felt that time and place were not too important as long as
the Fortran 88 message was put across.
Fortran Forum
With the present time-table for the publication of the new
standard Fortran 88 there will be another public review period
of about three months in late Summer 1989. The WG5 timescale of
publication of the new standard at their meeting in Italy in
July 1989 had already slipped. The meeting felt that another
Fortran Forum should be held to coincide with the public review
period to discuss and approve the final document of the standard pd
as well as some tutorials on the new features.
The venue for a Forum would be a problem at such short
notice but as it would probably be in the Summer holidays a
University could accommodate the required numbers. It was
suggested that either London or Liverpool might be appropriate
locations. It was proposed that a sub-group be formed with the
task of organising a Forum and, perhaps, liaising with BISL.
6. BCS BUSINESS
Presidential Visits
The Chairman, John Wilson, has received a letter from the
Specialists Group's'Technical Co-ordinator, Tony Sale, requesting
that this year's BCS President, Brian Oakley, be invited to an
ordinary meeting of the Group. It was decided that as the Group
met during the day, the Group's business was positively ordinary,
and that there are at least 40 other Groups as well as all the
Branches to visit, the President would not be formally invited
to attend a Fortran Group meeting.
Involvement in Standards
The Chairman, John Wilson, had nothing to report on his
approach to BCS seeking regular funding for attendance at WG5.
Apparently, the Group cannot use its usual grant but could
possibly use the profit from the Fortran Forums. John Wilson has
been told that there is a BCS special purposes fund but he could
not find out who operated it.
Technical Committee for Standards
The Vice-Chairman, Chris Lazou, has joined the Software
Engineering Technical Committee which is to provide support for
Specialist Groups. The terms of reference for the new Committee
are still to be finalised.
Specialist Group's Management Committee
The Chairman, John Wilson, attended the meeting which took
place on 2 November 1988. He reported on the following matters:
(a) The new Secretary had resigned.
(b) The next printing of the BCS Handbook would be in
September 1989. All updates are to be in by May 1989.
(c) There are 3 new Specialist Groups
(i) CASE: Computer Assisted Systems Engineering
(ii) GIS: Geographical Information Systems
(iii) SQM: Software Quality Management
(d) There had been two meetings held for Specialist Group
Treasurers. The BCS now have a centralised accounting
system which is being used by Branches but Specialist
Groups can opt out if they so wish.
(e) Mature members' applications for Chartered Engineer are
being processed very slowly. Unless the process is
speeded up it may be some years before some mature
members obtain CE.
7. ANY OTHER BUSINESS
Fortran Journal
A new Fortran publication called Fortran Journal described
as "The Journal for the Fortran User Community" has been
launched. The new Journal contains news items and has
advertising, software exchange, and the subscription includes
membership of the Fortran Users Group. Published in the USA the
editors are Walt Brainerd and Charles Ritz.
Programming Research Ltd Flier
The Managing Director of Programming' Research Ltd, Les
Hatton, requested that a one page flier on FLINT - a
comprehensive FORTRAN engineering toolset - be included in the
next mailing to members of the Group. This was approved with the
proviso of including the Group's standard disclaimer on
commercial products.
WG5 Meeting in Italy
The next meeting of the International Standards
Organisation's Fortran Standards Committee WG5 is to be held at
Ispra in Italy from 10-14 July 1989. Anybody wishing to attend
this meeting should give their name to David Muxworthy by
March.
8. FUTURE MEETINGS
The next meeting of the Group will take place on Thursday,
20 April 1989, in Oxford. The morning session will include the
AGM and the afternoon programme has yet to be arranged.
The meeting will be held in Oxford University's Computing
Teaching Centre at 59 George Street, Oxford by kind invitation
of the Treasurer, Miles Ellis.
The following meeting will be on Thursday, 29 June 1989, at
BCS HQ. This meeting will consider any items needed to
presented to WG5 in Italy.
John Young
Secretary
11 April 1989
To: Fortran Forum, BCS, NAG, etc.
From: John Reid
Date: 27th February 1989
Subject: X3J3 meeting in Stanford
Note: This is a personal note on the meeting and in no sense does it
constitute an official record of it.
[Note: This appendix was written after the meeting of 19 January 1989
but was included in the minutes of that meeting.]
1. Summary
The Chairman announced on the first day that her aim was to complete
consideration of all technical issues during the week, so that the
next meeting could focus on edits, bug fixes, and agreeing responses
to comments from the public. This aim was achieved. A letter ballot on
forwarding the document will now be held, and if this is successful,
proposals for changing the draft will be limited at the next meeting
to edits and bug fixes that are mentioned in the ballots. Her ruling
to this effect was accepted unanimously.
The result of the Chairman's informal letter ballot was 28-12-6, so it
looks as if the necessary two-thirds majority vote will be achieved in
the coming letter ballot (with a small margin). The principal reason
given for a no vote was the size and complexity of the language.
The result of the WG5 Convenor's informal ballot was favourable (7-0
by countries and 27-2 by individuals).
The major technical changes made at the meeting were:
1. Add pointers as a data attribute (retaining allocatable arrays).
2. Parameterize LOGICAL (without BIT properties).
3. Add nonadvancing i/o (formerly called stream i/o).
4. Allow structures in COMMON and EQUIVALENCE.
5. Limit the intrinsics permitted in data initializations and
KIND specifications.
6. Alter the rules on argument association of arrays to permit
new arrays to correspond to old dummy arrays.
7. Extend the DATA statement to array sections and derived types.
8. Add intrinsic functions FLOOR, CEILING, and MODULO.
Some of the votes were nail-bitingly close (see details below). The
effect is that action has been taken on all the major differences
between S8 and the plan P2 of WG5, but two significant differences
have been introduced: structures in COMMON and no BIT arrays. The WG5
Convenor is hopeful that WG5 will accept these changes, so plans to
ballot WG5 on a document that is identical to S8 except for the cover,
title pages, foreword, headers and footers, and change marks.
It looks hopeful that identical ISO and ANSI draft standards may be
issued for comment after the May meeting of X3J3.
2. Pointers
At the previous meeting, X3J3 adopted the addition of a pointer type
and explicit de-referencing for accessing pointer targets. However,
the availability of text and further clarification of the issues led
to some people changing their minds and straw votes indicated that it
was unlikely to get the support necessary for adoption, whereas the
WG5 proposal might. The WG5 proposal was changed so that pointers are
initially undefined and only become disassociated when the NULLIFY
statement or a suitable pointer assignment statement is executed, and
was adopted (25-12).
There was concern that users needing simple allocatable arrays would
need to understand pointers. Therefore, allocatable arrays were
restored (30-4), now without the ability to use them as dummy
arguments or function results. There may be advantages for
optimization since an allocatable array may be declared without the
TARGET attribute and this will prevent pointer access to it.
3. Parameterized LOGICAL
The parameterization of LOGICAL without any BIT connotations was
adopted (30-8). There is no requirement for LOGICAL (KIND=l) to be
represented as a single bit, though this is a possible
implementation. Note that this results in a uniformity among the
intrinsic types, all of which now have a KIND type parameter.
4. Nonadvancing input/output
For what had somewhat erroneously become known as stream i/o, the
Committee indicated in early straw votes that it preferred a facility
based on i/o statements to the use of intrinsic subroutines. It was
felt that there should be a form of the READ and WRITE statements that
does not automatically cause an advance to the start of the next
record. For lack of a better term, it was called 'nonadvancing' i/o. A
strong desire was also expressed (by me and others) for a means of
reading as many characters as the record contains and finding out how
many this is. The facility was refined by active subgroup work and was
eventually adopted unanimously. It involves only formatted sequential
access to an external file and the maintenance of a pointer to the
current character in the current record. It is specified by
ADVANCE='NO' and the number of characters processed is returned by an
optional NCHARS= specifier.
There is no longer a need for PROMPT=, so this was deleted.
5. Structures in COMMON and EQUIVALENCE
By exactly the same marginal vote as for pointers (25-12), a facility
that permits structures in COMMON and EQUIVALENCE was adopted. It
involves a new keyword, SEQUENCE, within a type definition. Separate
type definitions specify the same type if they have the SEQUENCE
property, have the same name, and have components that agree in order,
name, type, type parameters, and shape. A sequenced structure may
appear in COMMON or EQUIVALENCE, and may be storage associated with
another structure of the same type. If all the components ultimately
resolve into default numeric or default logical type, they must be
laid out in storage as in a COMMON block and the usual storage
associations are available (and similarly for default character).
6. Restricted constant expressions
It was decided to introduce a new category of constant expression, for
use in data initializations and KIND specifications but not in CASE
statements. It reduces the number of intrinsic functions permitted and
(presumably) makes evaluation at compile time easier, but the rules
will be hard for the user to remember. An intrinsic function reference
is permitted when
1. the arguments are restricted constant expressions of type integer
or character, the result is of type integer or character, and the
function is not DOTPRODUCT, MATMUL, an array reduction function
such as ALL, an array construction function such as PACK, an array
manipulation function such as CSHIFT, nor an array location
function such as MAXLOC;
2. the arguments are restricted constant expressions and the function
is RESHAPE; and
3. the function is an inquiry function and each argument is either a
restricted constant expression or a variable whose type parameters
or bounds inquired about are restricted constant expressions.
The motion was accepted (29-3) as a compromise towards those who want
a smaller and simpler language.
7. Argument association of arrays
Tom Aird of IMSL drew my attention to a problem with the argument
association of arrays. Many library codes use assumed-shape arrays;
under the old rules for argument association, these would not have
been permitted to be called with actual arguments that were array
sections, array expressions, or assumed-shape arrays. Also simply
adding an explicit interface for the sake of argument checking would
not have been permitted.
My proposed change allows sequence association with an explicit
interface and says that sequence association always takes place for
explicit-shape and assumed-size dummy arrays. The natural
implementation is for such arrays always to be stored contiguously,
which means that copy-in copy-out will be needed if the actual
argument is a discontiguous array. This led to some opposition, but I
pointed out that it will occur only in the transitional phase when new
arrays are being passed to old dummy arrays and will not occur for
existing programs.
Two snags were pointed out by the subgroup: a copy-in should not be
made for an actual argument that is an array element when the dummy
argument is a scalar, and resolution of overloads requires rank
agreement. I therefore added the requirement of rank agreement when
the actual argument is an element of a possibly discontiguous array
and for a generic call. The proposal was accepted (28-10).
8. Additional obsolescent features
None of my suggestions for additional obsolescent features was
accepted. I found it quite extraordinary that only 3 people supported
making obsolescent the calling of an external procedure without
declaring it in as EXTERNAL statement or an interface block, since
declaration in an EXTERNAL statement was recommended on page B-13 of
the Fortran 77 standard and is needed for upward compatibility of
Fortran 77 programs (see page 1-2 of S8). The whole concept of
language evolution appears to be rejected by a majority of X3J3. The
most favoured proposal in straw votes was the H-edit descriptor but
this failed (15-19) in a formal vote.
9. Minor changes
The following minor changes were made:
1. If a COMMON block appears in a module, allow objects in the block
to be declared PRIVATE, so that they are inaccessible via USE
statements (though still available through COMMON).
2. Rename the ARRAY attribute as DIMENSION.
3. Add EXTERNAL and INTRINSIC as attributes that may be included in a
type declaration statement.
4. Require agreement in type and type parameters of the elements of
an array constructor.
5. Allow the declaration of any sort of array in a DIMENSION
statement or attribute.
6. Extend the DATA statement to array sections and derived types.
7. Add intrinsic functions FLOOR (the integer just less than the
argument, for example FLOOR(3.7) = 3 and FLOOR(-3.7) = -4),
CEILING (the integer just greater than the argument), and MODULO
(mathematical modulo function, for example MODULO(8,5) = 3 and
MODULO(-8,5) = 2).
8. Allow DATA statements among the specification statements, provided
an array that appears in a DATA statement has its array properties
established in a previous declaration statement.
9. Allow statement functions to appear among the specification
statements.
10. Remove DATA attribute (simply allow initialization without the
need to specify DATA in a type declaration statement).
11. Extend DATA statement to array sections and derived types.
12. Replace the argument MOLD that gives a template for the KIND type
parameter of the result of many intrinsics by the argument KIND
that specifies the KIND parameter directly.
13. In the intrinsic DATA_AND_TIME, change 'Greenwich Mean Time' to
'Coordinated Universal Time' and require that all values returned
refer to the same instant in time.
14. The intrinsic REAL for a single complex argument takes the kind
parameter value of the argument.
15. Ensure that the right-hand side of a defined assignment is always
treated as an expression.
16. Require the argument MOLD of RESHAPE to have constant size, and
rename it as SHAPE.
17. Allow zero-sized objects in COMMON.
The following proposals were not accepted (votes are not given where
straw votes were so unfavourable that the proposal was not moved
formally):
1. Restore the FORALL statement.
2. Replace % by . for structure component selection.
3. Delete module procedures (10-29).
4. Add one-argument SIGN function (11-16).
5. Add intrinsic NUM_KINDS that returns the number of kinds and add
optional argument N to KIND to specify the N-th kind (22-12).
6. Allow the value 60 for argument SECOND of DATE_AND_TIME (17-16).
7. Allow RETURN in a main program (10-25).
8. Convert PACK and UNPACK to subroutines (9-21).
9. Language name should be Fortran 88 (11-17).
10. Allow more than one SAVE for an object (4-25).
11. Restore part of the VALUES= facility.
12. Lessen the restriction on the position of IMPLICIT statements
(16-17).
13. Add CPU_TIME intrinsic (21-13).
10. Appreciation of longstanding memberships
It was decided to request that CBEMA send letters of appreciation to
Jeanne Adams, Neldon Marshall, Lloyd Campbell, Walt Brainerd, Jim
Matheny, and Rich Ragan, who have all been members since 1976. This
was expected to be Jim's last meeting and he was given a standing
ovation.
11. Next meeting of X3J3
The next meeting of X3J3 will be in New York, 8-12 May. The deadline
for the pre-meeting distribution is 3 April.
SHORT HISTORY OF FORTRAN PREPROCESSORS
Abstract of the talk given by David Muxworthy, Edinburgh University
Computing Service
The term "Fortran preprocessor" is most commonly taken to mean a
program which translates a program written in an extended Fortran
language including control structures, and possibly omitting more
primitive standard Fortran ones, into compilable Fortran for a
particular implementation. Such preprocessors appeared mainly in the
early to mid-1970s following IBM's embracing structured programming
techniques as part of its Chief Programmer Team software development
technique; over 60 such preprocessors have been mentioned in the
literature. Well known names include IFTRAN, MORTRAN, RATFOR and
SHELTRAN (marketed as FORTRESS).
Ten years earlier automatic translators from Fortran II to IV had
established the precedent of programs, themselves written largely in
Fortran, to read and write Fortran source. Many other tools to
manipulate Fortran source and either print information about it or
output a transformed version have appeared. Examples include the
following.
1. Translators
SIFT - Fortran II to Fortran IV (Datamation March 1963 pp 43-46)
Dialect to dialect
Fortran to Fortran optimizer (1973)
Fortran to other languages (Algol, PL/I)
Other languages to Fortran
2. Analyzers and Documentors
Syntax checkers (PFORT 1974)
Frequency counters (UCL 1972)
Structure analyzers
Path analyzers (DAVE 1976)
Linkage analyzers
Source tidiers (DCE263 1968)
Flowcharters
Concordance generators
3. Program generators
Part program generators
Common/Equivalence Builder (1971)
Recursive Fortran (1975)
SHORTRAN (1976)
Structured Fortran preprocessors
RATFOR (1975)
SHELTRAN (1975)
Macro processors
FORMAPRO (1971)
Portable Fortran
PFortran (1975)
Master source systems
PSTAT (1975)
NAG (1976)
AUTOMATIC
VECTORISATION
GRAHAM BARBER
EDINBURGH PORTABLE COMPILERS LTD
[The 36 slides used in this talk have not yet been digitized.]