BCS - FORTRAN SPECIALIST GROUP
MINUTES OF MEETING HELD AT BIRKBECK COLLEGE ON 5 DECEMBER 1983
Present: J L Dyke - Huntingdon Research Centre
D J Holmes - Rolls Royce Ltd, Bristol
R F Maddock - IBM
Brian Meek - Queen Elizabeth College, London
David Muxworthy - University of Edinburgh
Keith Normington - Coventry Polytechnic
Mike Nunn - CCTA
T L Van Raalte - MOD
Nick Saville - Private Consultant
Lawrie Schonfelder - Liverpool University
David Vallance - University of Salford
John Wilson - University of Leicester
Addresses:
Chairman - John Wilson
Computer Laboratory
University of Leicester
Leicester LE1 7RH
phone 0533 554455
ext 165
Secretary - Mike Nunn
CCTA
Room 408
Riverwalk House
157 Millbank
London SW1P 4RT
Treasurer - T L Van Raalte
Atomic Weapons Research Establishment
Aldermaston
Reading
1. Minutes of Previous Meeting [26 September 1983]
Corrections:
(i) In first paragraph of "Matters Arising"
"OSI/5" should read "OIS/5"
The membership of OIS/5 subcommittee comprises:
D Muxworthy
B Meek
J Wilson
I D Hill
with P A Clarke and A M Addyman as correspondent members.
(ii) In appendix B paragraph 5.(x)
"rather arguments" should read "rather than arguments"
2. Matters Arising
(i) Treasurer's Report
Our Group has to put in an annual bid for funds from
BCS and for the coming year we are making a submission
for £505. This has to cover such things as hire of
rooms and refreshments for meetings, the newsletter
mailing list and the Group's ANSI observer's fee.
The Treasurer is trying to find the best way to pay
money to cover expenses incurred by J Roberts-Jones when
he was Treasurer. Mr Roberts-Jones has been very
difficult to contact.
(ii) Membership of BCS FORTRAN Specialist Group
Accompanying these minutes is a membership renewal form for
our group. This MUST be filled in and returned to the
Secretary. Non-BCS members are reminded that there is
a £2 fee for membership of the Group which for the
current financial year must have been sent to our
Treasurer, Mr van Raalte by the end of March 1984.
Otherwise membership will automatically be deemed to
have lapsed.
(iii) ISO FORTRAN Meeting at CERN, Geneva.
The FORTRAN experts meeting next April at CERN has been
slightly reconstituted as an ISO working group
[ISO/TC97/SC5/WG9] and those attending should be
"accredited delegates". Presently the Convenor,
Jeanne Martin (X3J3 Secretary), is putting together a
formal membership list. Those interested in attending
from the UK are asked to write to David Muxworthy
(Edinburgh University) so that BSI can formally endorse
them as delegates. Please contact him before the end
of January. His address is:
Program Library Unit
University of Edinburgh
18 Buccleuch Place
Edinburgh EH3 9LN phone O31 667 1081 ext2972
David also mentioned that there ought to be a UK FORTRAN
activity report for the CERN meeting. In the past he's
tried to summarise the BCS FORTRAN Group's reactions to
FORTRAN 8X at ISO meetings. In fact anyone who wants
any matters raised at CERN in relation to 8X should
write to our Chairman, John Wilson. The FORTRAN Inform-
ation Bulletin produced by ANSI X3J3 Committee summarises
the current state of 8X. John can supply those
interested with a copy for £2.
Brian Meek suggested that the ISO FORTRAN meeting should
be an explicit item on the agenda at our next meeting.
(iv) "British Standard Method of Specifying Requirements for
FORTRAN Language Processors"
Brian Meek was anxious that the BSI FORTRAN proposal
should be referred to as "British Standard Method of
Specifying Requirements for FORTRAN Language Processors"
and not as "British Standard FORTRAN" which was
misleading. He was also very concerned about what
various people said regarding the proposal in his
absence at the October meeting. In order to
clarify the position Brian has written a letter to the
Group which forms appendix A to these minutes.
3. BCS Business
(i) At the 10 November meeting of the Specialist Groups
Board a motion to seek a Royal Charter for BCS was
passed by 27-1. At the same meeting it was decided
to "unbundle Groups". In future BCS members will
automatically have free membership of one Branch and one
Specialist Group but will be charged if they want to
belong to others.
(ii) New Specialist Groups - Electronic publishing
- CAD (resurrected)
(i) A written summary has been received from John Reid (Harwell)
on the X3J3 meeting in Seattle on 14-18 November 1983
and is in appendix B.
(ii) Lawrie Schonfelder gave the Group the following verbal
summary:
X3J3 is about to switch modes - up to now they have been
working on lots of new material but things are now
reasonably complete so they are moving into editorial
mode.
A lot of time was spent on the FORTRAN Information
Bulletin to get it into a suitable form for submission
to X3. The S7 document itself is too big for publication
and also has a few holes. One body of opinion is that
S7 in trying to use a F77 type structure has imposed
too great a strain and that a further working document
S8 should be produced. However, it would be pretty
horrifying to attempt it at this late stage.
Instead a small task group has been asked to go away
and restructure S7 as well as they can.
FORTRAN structures discussed included:
Do loops - some discussion on format
Consistent functions - a proposal from John Reid but
the committee was not too happy
with the idea
[consistent functions have no
side effects and depend completely
on arguments]
Array processing - should additional intrinsic
functions COMPRESS/EXPAND be
included?
- IDENTIFY statement was further nu
discussed but problems with it
not resolved
generic statements - removed
- now provided by other means
date/time - intrinsic function for cpu time
was considered but there is
difficulty in deciding what is
meant by cpu time
event handling - got rather a rough ride and this
feature is in rather an unfinished
state
I/O - a few clean up proposals
bitstream I/O - tentative proposal with
unresolved problems including
breaking lots of other FORTRAN
rules
A draft of 8X for public comment is likely to be ready in 1986 and
the final version published in 1988.
5. Kernel Graphics
David Muxworthy reported that although the GKS Standard was still
going through the ISO processes it was essentially settled. It has
been published as British Standard 6390 and costs £26.
The present specification is only 2-D but a Working Group has been
asked by ISO to produce a 3-D extension by next June.
The proposed FORTRAN binding is up for public comment until March 1984
(see appendix C). Any comments should be sent to either David Muxworthy,
Jeanne Martin (X3J3 Secretary) or members of the ISO graphics
committee.
6. Any other Business
None.
7. Date of Next Meeting
(a) The next meeting will take place on Monday 27 February at
10.30 at BCS HQ, 13 Mansfield Street, London. In the
afternoon Steve Hague (NAG) will give a talk on Toolpack.
(b) The AGM is due to take place on 16 April.
8. Filmshow "The history of FORTRAN"
Bob Maddock of IBM kindly brought along and showed a film on the
early development of FORTRAN. It was fascinating to hear members
of the original team that developed the language, including its
leader John Backus, talking about how it all happened, It all
started in 1953 as an IBM research project and amongst its design
aims was to produce a compiler that could produce the most
optimised programs possible. Anyone else who would like to get hold of
the film should contact Bob at IBM UK Labs Ltd, Hursley Park,
Winchester, SO21 2JN.
[The film is now available at the Computer History Museum. For further
information and a link to the film see
http://www.fortran.bcs.org/2007/jubilee/film.php]
9. Derived Data Types in FORTRAN
In the afternoon Lawrie Schonfelder, of Liverpool University gave
a talk on the proposed derived data types for the next FORTRAN
Standard. A synopsis follows and in appendix D is an excerpt from
the FORTRAN Information Bulletin which defines them.
Derived data types are types defined by the user as aggregates of
intrinsic type objects.
(i) Specification
TYPE type name [(param list)]
component field declaration
[component field declaration]....
ENDTYPE
example
TYPE STOCK - ITEM
ID: INTEGER
DESC: CHARACTER (LEN=2O)
QUANTITY: INTEGER
PRICE: REAL (PRECISION=6)
ENDTYPE
(ii) Structure Declaration
Names for derived data types may be declared similarly
to those for objects of intrinsic type:
TYPE (type-name [(param-list)]
name [(array-dec)][,name (array-dec)].....
is an attribute oriented "type statement".
name [,name]......: TYPE(type-name[(Param-List)]
[,attribute list]
is an entity oriented "declare statement".
(iii) Attribute lists look like:
attribute list is attribute [,attribute]
attribute is DIMENSION (array-dec)
or INITIAL (expr)
or SAVE
or IN etc
A structure component can be referred to by qualifying the
structure name:
Structure-name % component-field-name [(array-selector)]
[(sub-string)]
eg WORD % LENGTH
LINE % CHARS (1:LINE % LENGTH)
(iv) MODULE/USE
Structure is:
MODULE mod-name
type and object declarations [PUBLIC and PRIVATE]
internal procedure definitions
[PUBLIC and PRIVATE]
external procedure definitions
[PUBLIC and PRIVATE]
ENDMODULE
USE [/mad-name/] ONLY ([aocess-list])
or
USE [/mod-name/] [ALL(rename-list)]
[EXCEPT (name-list)]
FUNCTION PROCEDURES
These look like:
[INTERNAL] [RECURSIVE] [typ] FUNCTION fun (d-arg-list)
[RESULT(res)][OPERATOR (op=)]
Similarly for SUBROUTINE PROCEDURES.
(vii) I/O is still a problem. At present components of a
structure have to be written out one at a time. Using
formatted I/O what will be needed is a user defined
format specifier.
Mike Nunn (Secretary)
12 January 1984
QUEEN ELIZABETH COLLEGE
(UNIVERSITY OF LONDON)
COMPUTER UN|T CAMPDEN HILL ROAD, W8 7AH
DIRECTOR BRIAN L.MEEK,M.Sc. TELEPHONE: 01-937 5411
TELEGRAMS: QUEENBETH.LONDON W8
Mr Mike Nunn 5 December 1983
CCTA, Room 408
157-161 Millbank
London SWlP 4RT
Dear Mike
BCS Fortran Specialist Group
I was very concerned at the minute of the meeting of 26 October 1983
concerning the proposed British Standard 'Method of specifying
requirements for Fortran language processors' since the discussion it
reports displays a profound misunderstanding of the nature of the
proposed standard. Could these notes therefore please be appended to
the next minutes?
The proposed standard is an indirect standard, not a direct one. It is
not a 'British Standard Fortran', and perhaps the first thing to do is
to change the heading in future to 'British standard for specifying
Fortran processors'. However, even then the proposed standard does not
specify a 'standard conforming processor' which Fortran implementors
must follow. What it does do is define a standard way in which the user
of a Fortran system can specify what properties he wants from that
system. To be sure, one possible use of the proposed standard is to
produce a very tight specification for a Fortran system, which would
place many specific requirements on the implementor. However, a
standard can be used in many ways. At the other extreme, an individual
could use it as a checklist, which would draw his attention to features
of implementations that he has not thought of, or has taken for granted,
without his ever producing an explicit specification (whether for the
production of a processor, or for the supply of a processor, or for
testing a processor). Even if he produces a specification, he could use
it as a set of guidelines without ever needing to claim that the
specification actually conforms to the standard. Yet even at this
minimal level of picking out the individual elements of importance to
the particular user, the proposed standard will be of value.
Nevertheless it is hoped that users in general will base their
specifications and evaluations for Fortran processors on the standard as
a whole and not just on a selection of elements, since the standard is
designed to ensure a much higher level of portability of Fortran 77
programs between implementations, and much greater predictability of
what will happen when a program runs, than the ANSI standard on its own
attempts to guarantee. However, it is still the user who determines
whether the processor meets the specification, not the standard.
[new page]
If I may comment on the particular points made in the minutes, I think
it is very unfair to ask us to show 'concretely' how this project will
improve the ANSI standard, when its content is still under discussion.
However, there are many specific examples of problems caused by
deficiencies of the ANSI standard, and anyone who is aware of them or
thinks they are not important is living either in a dream world or in a
very sheltered environment. As for the reasons the ANSI standard leaves
things undefined, the group is very well aware of them and are taking
them into account. As for casting the language in 'concrete' (clearly a
favourite word!), the proposed standard is not about the language at
all, but about implementations. It is accepted that people will want to
'sell' implementations in the traditional way, on 'features' rather than
on quality. Clearly by the time it is published, there will be things
coming out which will be in 8X, or people think will be in 8X, or people
wish to try to ensure will be 8X. The proposed standard would not
preclude them. However a processor specification produced in
accordance with the standard would require them to be flagged as
non-standard; require a 'standard mode' of operation in which they
would be rejected; require them to be documented, and defined in the
same way as in the ANSI standard, and if possible expanded into
conforming Fortran 77 code.
As for U.S. companies 'not being interested', if we take that attitude
we might as well give up any attempt to influence ANSI X3J3 or anyone.
It is in fact very unfair to the many in the U.S.A. who do care what
people abroad say. I believe responsible implementors do exist and will
welcome the guidance this proposed standard will give, and that this is
true regardless of their nationality.
Our aim in this project is to enhance the value of the ANSI standard and
promote its use. An important element is to demonstrate that it can be
done at all, and without causing horrendous problems for implementors.
In any case, a 'permissive' approach to standard ought to allow to those
who wish it, the possibility of foregoing some of the variability the
permissiveness allows!
I hope that in future people will try to understand our intentions, and
at least wait to see what we produce, instead of prejudging the issue.
Yours sincerely
B. L. Meek
To: NAG, BCS, DAP unit, etc.
From: John Reid
Date: 22nd November 1983
Subject: Report on Seattle meeting, 14-18 November 1983
References
[1] 88(*)JLW-1a Fortran Information Bulletin
[2] 87(11)JKR-6 Removal of a restriction concerning
internal files
[3] 88(11)JKR-9 On the character set
[4] 88(*)JKR-10 On the choice of built-in names
[5] 88(11)JKR-11 On the significance of blanks
[6] 88(11)JKR-12 Enhanced I/O operations to computer
terminals
[7] 88(8)JKR-2a Consistent functions
[8] 88(6)RAH-1 Deletion of ALT
[9] 88(6)AW-1 Compress/expand
[10] 88(6)MS-1 Assumed-shape array
[11] 88(6)MS-2 Array names in dimension bound expressions
[12] 88(6)JKR-3a Deletion of OTHERWISE
[13] 88(6/9)JKR-5a Changes to IDENTIFY
[14] 88(9)JLS-2 Parameterized data types
[15] 87(*)JKR-5 Intrinsics for date and time
[16] 87(7)KWH-1 An exception handling control structure
[17] 88(7)KWH-1 An exception handling control structure
[18] 88(11)JHM-1 SG11 clean-up proposals
[19] 88(11)NHC-1 Unformatted binary i/o
1. Summary
The only major proposal passed at this meeting was the formal
acceptance (22-0) of Jerry Wagener's Fortran Information Bulletin. A
fair amount of committee time was spent considering detailed changes.
A large number of editorial changes were made to S7, which
will mean that the next version is a bit cleaner . However it is still
not a satisfactory document. A small "task group" was set up to
consider how it might be improved or replaced.
Most of the full committee time was spent considering suggestions
not yet ready for formal votes. Four full afternoons were spent in
subgroups.
2. Block DO syntax
A four-way straw-vote on syntax went thus:
DO...REPEAT :8, DO...END_DO :9, LOOP...END_LOOP :4, undecided :1.
Using : in DO was favoured (1O-6-6) and another 4-way vote went this
DO(N TIMES) :8, drop (N TIMES) :2, DO(1:N) :8, undecided :2.
3. Consistent functions
I discussed my proposal [7] on consistent functions with subgroup
7/8 who in turn asked me to speak to the full committee. The subgroup
pointed out that Alan Clarke was asking for consistency throughout
program execution, that I was asking for consistency very locally
(during a single reference or set.of FORALL references) and that other
"lifetimes" were desirable, e.g. so that a compiler on asynchronous
hardware could execute these statements in parallel
A=FUN (B)
C-FUN2(D)
E=FUN (F)
The full committee was concerned about error handling, or even the
simple passing back of an error flag. Straw votes were not in favour
of Alan Clarke's idea (6-11-15) or mine (4-10-16) and little better
disposed to an intermediate lifetime (8-3-22). Given that a
satisfactory definition of consistency can be agreed, the committee
wanted (14-3-13) a suitable assertion statement.
4. Array processing
The proposal [8] to delete ALT, whose functionality is now
available via array constructors, passed 22-0. The proposal for the
new intrinsics COMPRESS and EXPAND [9] was favoured (17-1-17) but
deletion of PACK and UNPACK was not (0-12-24). It was agreed that a
major rewrite of Chapter 14 of S7 (on intrinsic functions) was needed
with a proforma description of each (37-0-1) and that all intrinsics
should continue to be included (32-1-4). Alan Wilson and I were
charged with the task of preparing sample rewrites for the next
meeting. The tidying-up proposals [10] and [11] were passed by 17-5
and 22-1.
In the subgroup, my proposal [12] to delete OTHERWISE
failed (2-5-0), but a complete rewrite of the description of WHERE
blocks in S7 was agreed. On the IDENTIFY, my suggestion [13] to
extend it to scalars as an aliasing mechanism was accepted by the full
committee (19-2-11), my suggestion to extend it to structures was
accepted by the subgroup (4-0-3) and my suggestions to make an
identification cease when the parent is reallocated or reidentified
were accepted (21-0-9) and (11-8-14).
There was total disagreement in the subgroup over many-one
mappings in vector-valued subscripts and IDENTIFY statements. There
was also disagreement over restricting the number of IDENTIFY
statements within which a virtual array name may appear. I will
prepare a new proposal excluding these issues.
5. Parameterized data types
Lawrie Schonfelder's proposal [14] on derived data types (which
for example, would allow a derived type MATRIX to be parameterized by
precision and order) was accepted in principle (18-3-13) but withdrawn
for detailed changes.
A proposal to remove the GENERIC statement was passed 25-0. The
functionality is now provided by procedure overloading.
6. Date and time
There was broad agreement on the need for date and time
intrinsics but my proposal [15] which follows an existing standard
slavishly was not liked (9-17-7). I will prepare a fresh proposal
that returns the same information and makes use of the enhanced
features in F.8x. I asked for a discussion on the need for a CPU time
intrinsic and it was clear that this has much less consensus (straw
vote on the principle: 16-13-7) so I propose to work on date and time
only for the present.
7. Event-handling
The present event-handling features are not progressing well.
Detailed changes were not welcomed while the facility does not yet
provide any useful functionality. Hirchert's alternative ([16],[17])
is better understood and the static connection to the handler is
preferred strongly by some committee members. Straw votes (just)
liked ENABLE as a control structure (10-8-15) and as an exception
mechanism (12-8-13).
8. Pointers
Linda O'Gara presented a tutorial on pointers and sentiment
appeared to be largely in favour. It was felt that if pointers were
adopted they should be permitted to point to arrays (28-0-5) and that
ALLOCATE and FREE would no longer be needed (15-6-14). For syntax,
three alternatives were considered, illustrated by the case where A
and B point to rank one arrays:
The three statements are assignment of the pointer, assignment of an
element of the array and assignment of the whole array. A straw vote
(17-10-1-6) favoured the first alternative.
9. I/O Proposals
Some minor clean-up proposals (A,C,D,E,F and I of [18])
were passed. There was much discussion of proposal E3, the problem
being that one may not want padding, e.g. when reading from a tape
with fixed record lengths. Eventually a vote
(13-5-7) favoured functionality of padding under the control of an
additional specifier in the READ statement.
Unformatted binary i/o [19] was discussed without reaching any
firm conclusions, through there was sentiment in favour of stream i/o.
Note that BIT type is not in the language.
The remaining 15 pages of this document have not been digitized.
2.4 Derived Data Types
The structure of a derived data type is a programmer-defined aggregation of
fields, each field being a data element of primitive type (or another derived
data type). The aggregation pattern may be fixed or variant (that is, par-
tially dependent on one of the prior fields). A derived data type is defined
with a TYPE construct; variables of this type may be declared in the normal
manner. Intrinsic operations on derived data objects are assignment, equality
comparison, input/output, and use as procedure arguments. These intrinsic
operations may be augmented with additional programmer-defined operations.
The structure qualification symbol (for referencing a component of a struc~
tured object) is the percent sign (%).
structure-definition is TYPE type-name
[field-declaration]...
[variant-case-block]
END TYPE [type-name]
variant-case-block is SELECT CASE (tag-field-name)
[ CASE case-selector
[ field~dec1aration]... ]...
[ variant-case-block ]
END SELECT
field~declaration is type-declaration
or declare-statement
component-reference is structured-object-name % field-name
type-constructor is type-name (expr[,expr]...)
type-constant is type-name (constant-expr[,constant-expr]...)
Notes and Examples -
~ Functions may return derived data type values.
- The following definition of PLOT_OBJECT defines a data structure
made up of two fields of type real (the location in two-space),
one field indicating the nature of the object, and finally the
object data itself. In this case the object may be either a point
symbol or a line segment.
type PLOT_OBJECT
X0,Y0: real ! object location
CODE: integer ! type of object
select case (CODE)
case (1); SYMBOL: character ! point symbol
case (2); X1,Yl: real ! line segment
end select
end type PLOT_OBJECT
Let P,Q: type (PLOT_OBJECT) declare two variables P and Q.
Then the following expressions are examples of valid operations:
( P%X0 + Q%X0 ) / 2 ! mid-point of P and Q along X
if (P%CODE.eq.Q%CODE) then ! compare P and Q CODE fields
P = PLOT_OBJECT(0.,0.,1,"+") ! give P an initial value
read *, Q ! input value of Q