BCS - FORTRAN SPECIALIST GROUP
MINUTES OF MEETING HELD AT BCS HQ 27 FEBRUARY 1984
Present : Jackie Bettess University College of Swansea
S Brazier GMW Computers
M W Clark Imperial College Comp Centre
J Elkin KBC Process Consultants Ltd
W Flexner Retired
Joyce Graves University of Nottingham
D Holmes Rolls Royce Ltd Bristol
J Murchland (Part-time acting Secretary)
D Littlewood NCC
D M Vallance University of Salford
T L van Raalte MoD (Complementary acting secretary)
S Watkins UMIST
A Westlake International Statistics Centre
J D Wilson University of Leicester (Chairman)
(AFTERNOON)
F E Cox Swifte Computer Systems Ltd
M R Dolbear B P International Ltd London
D Everett Computer Graphics, University of Leicester
D Fordred BBC
S J Hague NAg
W S Hilder National Children's Bureau
R Iles NAg
Naresh Mooljee Edinburgh Regional Comp. Centre
L R Rice Nat. Inst. Biol. Stds. and Control
1. MINUTES OF PREVIOUS MEETING [5 December 1983]
(i) In 2(i) the submission made was for £607 (not £505)
(ii) In 3(i) the sentence "In future ... others" is a proposal and
has not yet been decided.
2. MATTERS ARISING
(i) Finance
A letter has been received from the Vice-President (Specialists Groups)
indicating that the FSG is likely to get the budget of £607 requested.
The Chairman has asked for support for regular attendance at the ISO
Fortran Experts meeting in Geneva. The amount involved would be about £1000
in alternate years. An encouraging reply had been given.
The Treasurer has written to the former Treasurer in order to obtain
some form of a claim against which to make payment.
(ii) "British Standard Method for Specifying Requirements for FORTRAN
Language Processors"
The working group has completed a draft which will go before OIS/5
for approval. A final draft is expected to be available from BSI shortly for
public comment.
3. BCS BUSINESS
(i) The Specialists Group Board Meeting was held on 9 February. The
proposed policy of unbundling while in abeyance regarding the membership of
Specialists Groups is under consideration regarding the choice of documentation
which members will receive.
(ii) The BCS is updating its list of book reviewers. Groups were asked to
propose a contact who will organise reviews. Will anyone interested in
reviewing or organising reviews give their names to the FSG Secretary (whose
address appears in the last minutes) in time for the AGM on 16 April.
(iii) The BCS is considering the establishment of a pilot BT Gold Mailing
box scheme. Groups will be advised.
4. ISO FORTRAN MEETING IN GENEVA
(i) Anyone interested in attending this meeting must get in touch with
D Muxworthy at the Edinburgh Regional Computing Centre in order to have his
name officially approved by the BSI.
(ii) Anyone who wants an issue to be raised at the meeting should inform
D Muxworthy or J D Wilson in writing as soon as possible.
5. X3J3 PROGRESS
(i) ANSI has not been accepting new proposals since November 1983, though
it is thought that this might not apply to minor modifications. The further
stages in the timetable are expected to be:
Feb. 1985 : Publication of the proposals for the new standard
Mid 1987 : Publication of the new standard after two years
consideration of public comment.
[A report on the February 1984 X3J3 meeting is appended.]
(ii) There was some discussion on progress of the standard.
(a) J Murchland said that there is a need for work to test the vali-
dity of the standard. Vallance agreed but pointed out that such work
needed substantial financial support.
(b) J Murchland raised the question of the measurement of time in
programs. He suggested that there should be standardisation outside
Fortran to which Fortran conforms.
(c) J Murchland considered that the need to extend libraries implies
the need for standardised names.
(d) J Murchland asked whether there is a guarantee that F77 programs
can be run under 8X. Wilson expressed doubts but could not give a
definitive answer.
6. ANY OTHER BUSINESS
(i) D Muxworthy would like to hear from anyone who is interested in a
program for converting from nH to character string formats.
(ii) Mike Nunn can supply copies of a first draft of a CCTA note on the NCC
Fortran validation scheme.
(iii) J Murchland drew attention to the Annals of the History of Computing,
vol. 6 which is devoted to the history of Fortran.
7. NEXT MEETING
The next meeting of the Group will be the AGM. It will be held on
Monday 16 April 1984 from 10.45 to 16.00 at BCS Headquarters. It will
include a report from the Geneva ISO meeting.
T L van Raalte (Treasurer/Acting
Secretary)
M Nunn (Secretary)
26 March 1984
To: BCS and NAG
From: John Reid
Date: 11 February 1984
Subject: Report on X3J3 meeting at Austin, 6-10 February, 1984
References:
[1] 89(7)KWH-1 An exception handling proposal
[2] 89(2)DTM/JAMS-1 Revised event handling improvements
[3] 89(6)JKR-1 Minor technical changes to the array intrinsics
[4] 89(6)JKR-4 Zero sized arrays and the data statement
[5] 88(6)AW-3 Array constructors: an enhancement
[6] 89(6)AM-1 Changes to the ALLOCATE mechanism
[7] 89(6)LJO-3 Array section selectors revisited
[8] 89(6)RRR-1 Block WHERE construct
[9] 89(9)JLS-2 Parameterized data types
[10] 89(9)JKR-2a Intrinsics for date and time
[11] 89(6)JKR-3a Changes to the IDENTIFY statement
[12] 89(11)JKR-5 Length of lines and statements in source form
[13] 88(11)JKR-11 On the significance of blanks and the underline character
[14] 89(9)LJO-2 Pointers revisited
l. Summary
The chairman sought to inject a sense of urgency into the
committee. Her aim is that at the February 1985 meeting the committee
should agree that S7 (or another document that replaces it) is
suitable for sending to the parent committee, X3, for release for
public comment. She therefore asked for firm plans from each subgroup
for proposals matching such a time frame and proposed to disallow any
technical proposals not included in these plans. I support her aim,
but am worried about the ban on other technical proposals especially
since no written list of subgroup proposals is available. It is
important to avoid wide-ranging new proposals which would have a major
impact on the language and require rewriting large amounts of S7, but
I believe that minor proposals should be allowed to be discussed while
the major effort is devoted to improving S7. Hopefully, common sense
will prevail.
2. Rewriting S7
Lawrie Schonfelder totally rewrote most of Chapter 4 of S7.
This concerns data types and is needed because of the inclusion of
derived data types in the language. It was accepted with minor
amendments (23-0). With Alan Wilson I am undertaking a total rewrite
of Chapter 14 (detailed specification of the intrinsics) and the parts
of Chapter 13 that this hinges upon. This is needed because the new
intrinsics are written in the Fortran 77 style which does not lead to
a clear description of functions that are much more complicated than
the Fortran 77 ones and does not define keywords for the arguments.
Our rewrite is not complete yet. We obtained useful comments from the
committee. The desirability of defining keywords for all arguments
was supported (23-3-4) and the overall approach was welcomed (34-0-0).
3. Event handling
There was a discussion as to whether event marks should
constitute a data type and a straw vote was unfavourable (2-14-10).
The problems are that event mark values are changed as side effects of
the execution of ordinary statements, and that assignments of event
marks cause side effects. It was suggested that the need for event
marks could even be avoided completely by attaching events directly to
handlers.
Kurt Hirchert brought a draft S7 chapter [1] on his exception
handling proposal before the committee and a straw vote approved it
(21-0-11). He recognized that it was written too hurriedly for it to
be ready for inclusion in S7. If this is accepted, it will be
desirable to drop the present event handling facilities or modify them
to exclude exceptions.
While it is clear that the present event handling facilities
remain controversial, it was agreed that David Muxworthy's
modifications [2] were improvements and proposals 1,3,8,11,12,14,15,16
of [2] were approved (18-0,18-2,15-0). He did not move proposals
associated with event-marks as a data type.
4. Kahan presentation
Kahan gave a presentation on behalf of the IEEE floating-point
standardization committee. His requests were for
i) the details of exceptions to be left to the manufacturer
ii) compiler optimization to be performed only if it leaves
results unchanged to the last bit
iii) for the precision of the arithmetic used for floating-point
subexpressions, to allow i) dominant mode, ii) widest precision and
iii) strict matching; and to provide a means of finding out which is
in use
iv) put nothing in the standard about required precision and
range for elemental intrinsics such as SIN.
v) avoid moving the evaluation of constant expressions to
compile time in case this means that no exception is raised at run
time when it should be
vi) require the implementor to supply information about certain
undefined results.
5. Array processing
My minor changes [3] to the array intrinsics were approved.
They are
i) extend array intrinsics to apply to derived data types, where
appropriate (22-0)
ii) change the DIAGONAL intrinsic to require the diagonal
elements in a vector and have an optional fill argument to provide a
value for off-diagonal elements (24-0)
iii) provide generic names for functions having only specific
names (23-0)
iv) rename 'SHAPE' to 'RESHAPE' and 'EXTENT' to 'SHAPE' (18-1)
My proposal [4] to allow zero-sized arrays in DATA statements
was accepted (21-0).
Alan Wilson's suggestion [5] to allow rank one arrays within
array constructors was passed (20-0).
Alex Marusak's proposal [6] to allow arrays to be reallocated
while preserving their data, was not accepted (4-8-17). Except in
rank one cases, reallocation is likely to require a copy anyway and it
was felt preferable to use a fresh allocate, a copy, and a free of the
old version. This also makes it clear what happens to virtual arrays
mapped into the allocated array (they need reidentifying).
Linda O'Gara suggested [7] using square brackets for array
sections to avoid the confusion with character substrings, but this
was not liked (5-18-10) principally because of worries over hardware
that does not represent these characters.
Rich Ragan's motion [8] to tidy up the description of the WHERE
block was passed (23-0). WHERE blocks may not be nested but were
described as if they can, with a maximum nesting level of one.
My proposals on the IDENTIFY statement [11] were passed (20-4),
subject to minor changes. These proposals are
i) to permit scalars and whole arrays to appear (i.e. provide
an aliasing facility)
ii) to allow the parent to be an array of structures with array
components and index both levels of subscripts
iii) establish that execution of an IDENTIFY statement sets up a
mapping from actual storage to a virtual array.
6. GKS binding
The GKS binding was discussed briefly. Concern was expressed
about the number of names imported into a user program.
7. Parameterized data types
Lawrie Schonfelder's proposals to use the keyword TYPE in place
of FORM and to allow attributes in derived data types ([9], proposals
A(i) and A(ii)) were passed (19-1 and 16-1). The previous problems
over optional specification of attributes were resolved by making
their specification non-optional, which is not a serious loss.
There was some discussion as to whether the operators =, .EQ.
and .NE. should have default definitions and a straw vote eventually
favoured having default definitions and allowing them to be redefined
for derived data types only.
8. Date and time
After considerable amendment and discussion, my proposal [10]
for intrinsic subroutines to return the date and time were passed (21-6).
The principal changes were to specify that local time is
returned, permit GMT to be calculated and return impossibly large
negative numbers when there is no facility.
A straw vote on a CPU-time intrinsic was favourable (23-6-5).
9. Source form
The committee discussed Peter Kirby's suggestion [12] that no
minimum required length for lines in free source form should be
specified. Subgroup 11 favoured raising the limit to 256. They did
not want no limit because then a compiler that only accepts lines of
(say) length 40 would still be standard-conforming. The committee
agreed that some number was necessary (24-4-4) but did not like 256
(8-2-19) nor any number greater than 132 (6-12-11).
The committee also discussed Peter Kirby's suggestion [13] to
treat underscores as nulls within keywords, identifier names and
numeric constants. They did not like this within identifiers since it
might make two versions of the same name look very different (2-10-3)
but they were well disposed to the idea within numeric constants (8-2-5).
l0. Pointers
Linda O'Gara led a discussion [14] on pointers. She felt that
Hoare's recursive data structures would not provide an adequate
replacement (see [14]) and this was confirmed in discussion. The
Seattle straw vote on syntax in favour of an extra symbol being needed
when the pointer is referenced (but not for referencing the pointee)
was confirmed (13-4-6). Concern was expressed about the wide effects
on the language that would arise from adoption of pointers. A vote of
l0-6-11 favoured continued work on the topic.