BRITISH COMPUTER SOCIETY - FORTRAN SPECIALIST GROUP
Minutes of meeting held at BCS Headquarters on Monday 1 June 1981
Present: J D Wilson (Chairman) Leicester University
D M Vallance Salford University
B Appleyard BP Oil
M Nunn CCTA
P A Clarke Rothamsted Experimental Station
T L van Raalte MoD
D T Muxworthy Edinburgh University
S G Brazier Structural Dynamics Ltd
J Roberts Jones Liverpool City Council
J D Murchland
1. APOLOGIES FOR ABSENCE
Apologies were received from Dr A Wilson (ICL).
2. MINUTES OF PREVIOUS MEETING [6 April 1981]
Item 9 should read X3J3 not X3Js. Mike Metcalf is spelt as shown here.
3. MATTERS ARISING
3.1 Future meetings
Alan Wilson has arranged for Professor Parkinson to speak at QMC on
7 September 1981. His talk is entitled 'Parallel processing - what is it?'
Brian Shearing has agreed to speak on Portable Fortran on 30 November 1981
(this meeting will probably be held at Salford University).
The Secretary will write to Professor Parkinson and Brian Shearing to Action
confirm these arrangements. D M Vallance
The start time for the meeting at Salford will be decided after British
Rail timetables have been consulted so as to minimise expense and
inconvenience to members of the group.
The secretary was asked to contact Anton Walter (Harwell) as a possible Action
speaker for the meeting on 1 February 1982. D M Vallance
The secretary Offered to speak on the subject of Fortran Compiler
writing on 5 April 1982 if the Committee so wished.
3.2 ISO programming languages meeting
The ISO programming languages meetings takes place from 5-9 October 1981
at ICL's Beaumont location.
The Chairman has written to the BCS secretariat recommending BCS
support for this meeting.
A reply was received which has been sent to Brian Meek for his further
action.
We are awaiting the ex~Chairman's signature in order to effect the Action
transfer of the Group's bank account from Barclay's to Lloyds Bank. J Roberts-
The Treasurer will contact Brian Meek regarding the previously agreed Jones
£50 donation to the ISO meeting when the Group's funds are 'unfrozen'.
3.3 Salford Fortran 77 Seminar
This seminar has been cancelled owing to lack of bookings.
4. TREASURER'S REPORT
The accounts have been audited and must be presented on a receipt and
payments basis and not on an income and expenditure basis. A copy
of the accounts appears as Appendix A of these minutes.
5. BCS BUSINESS
5.1 Specialist Groups Board
There was a meeting of the Specialist Groups Board on 14 May 1981
at which the Chairman was present. The following points emerged
from that meeting:
5.1.1 Committee members
New rules state that all committee members of specialist groups should
normally be members of the BCS. Group committee members who are not
BCS members require permission from the Vice-President (Specialist
Board) or from the President in the case of a Chairman who is not a
BCS member.
A lenient view will, however, be taken this year. The Chairman has
written to the Vice-President on behalf of the FSG's non-BCS members.
5.1.2 Profits from conferences
The current rule is that 60% of any profit goes directly into BCS funds
and the remaining 40% to the Specialist Groups Board.
A proposal is to go to the BCS Committee that 25-50% of any profit
should go to the organising group and the remainder to the BCS which
would itself decide how to split this between the Central Fund and
the Specialist Groups Board.
5.1.3 Annual accounts
Annual accounts should be submitted before the end of May in the year
to which they refer.
5.1.4 Annual report
The Fortran Specialist Group's written annual report was prepared by
the Chairman and handed to the BCS Secretary General. (See Appendix B
of these minutes.) [The report actually appeared as Appendix A of the
minutes of the following meeting.]
5.1.5 Publications Committee
A new Publications Committee has been established to standardise production
of BCS publications such as monographs. It is suggested that each group
should aim at producing one every 5-6 years.
5.1.6 Specialist Group Meetings
The BCS is planning to produce a programme card to be enclosed with
COMPUTING, giving details of all Specialist Group meetings. It was
also suggested that a paper in the Bulletin could be dedicated to this
This implies that we must arrange at least the dates of all our meetings
for a complete year in advance.
5.1.7 BCS AGM
Wednesday 21 October 1981 at the Wembley Conference Centre.
5.2 Buffet lunches at FSG meetings
There was general agreement that the FSG should try a buffet lunch at
the February meeting.
5.3 Expenses for speakers
It was noted that some groups budget for expenses for visiting speakers
and for travelling expenses for committee members.
6. FORTRAN FORUM
The Chairman will invoke the mechanism in order that the Forum will be
an official BCS event.
In arriving at the cost of the Forum, the Treasurer had made a number
of assumptions based on the experience of the previous Forum.
David Muxworthy agreed to circulate a draft programme for comment by the
organising committee, once agreed, this programme would be circulated
with the minutes.
THIS PROGRAMME AND AN APPLICATION FORM ARE ENCLOSED [Not available for digitising.]
7.1 Numerical Precision
Brian Smith has put in a new proposal on numerical precision for the May
meeting of X3J3.
7.2 Conformity
Alan Clarke has been developing the 'conformity issue'. A draft
is now available in word-processed form at Edinburgh University.
A major problem is that Alan Clarke and David Muxworthy cannot get
to X3J3 to press their ideas further. X3J3 accord exception handling
in Fortran because it can potentially restrict extension of the language.
There is a view that individual implementors should be left to provide
sensible action for exceptions.
The original conformity proposal was for Fortran 77. If adopted,
it would now be a part of Fortran 8X. The proposals will be amended
using the X3J3/S6 document as a basis. The Fortran 77 proposal will
be circulated to as many influential people in NBS/X3J3/BSI/CCTA as
possible.
7.3 Macros
Alan Clarke presented an overview of Fortran syntax macros which are
currently being considered by X3J3 for inclusion in Fortran 8X.
Appendix B is a draft of Alan Clarke's paper. He has also produced a
bibliography relating to macros in high level languages.
[The next meeting was held on 7th September 1981]
8. Afternoon Session
Dr John Murchland gave a talk entitled "Fortran 1, RATFOR and the
Software Tools Package", in which he traced the development of Fortran
and the reasons for the existence of RATFOR and the now widely available
Software Tools Package. Valuable discussion ensued as the features of
RATFOR were compared with those now available in Fortran 77.
THE BRITISH COMPUTER SOCIETY
Fortran Specialist Group
Receipts and Payments Account for the year ended 30th April, l981
(Please submit to HQ by 31st May)
£. p. £. p.
Balance at beginning of year
Bank 298.02
Cash 43.00 341.02
Add: Receipts
HQ Allocation 241.48
Other income (Please specify) Subscription 2.00 243.48
Total balance and receipts 584.50
Less: Payments
£. p.
Meeting Expenditure 32.30
Group Mailing 209.08
Secretarial 6.60
Committee
Professional
Project
Other Expenditure
(Please specify)
Total Payments 247.98
Balance at end of year - See note below (A) £336.52
Note 1. The balance at the end of year was made up of:
Bank 336.52
Cash -
(B)£336.52
(A and B should agree)
The Benefits of Macros in Fortran
Because macros and compile-time facilities can be used for such a wide
range of purposes, it is important to allocate some priorities to each of
these to determine where effort should be expended to bring the greatest
benefit.
High Priority compile-time features
1. INCLUDE-like facility for substitution of blocks of text into subprograms.
Benefits:
(a) Better project management control over COMMON (or data structure)
definition.
(b) COMMONS need only be manually changed in a single place (i.e in the
INCLUDE file) and not throughout all subprograms - resulting in higher
consistency and safety.
(c) Reduction in storage required for source text of programs.
2. Inter-procedure communication. This consists of providing keyword
arguments and compile-time checking of arguments and dummy arguments.
Benefits:
(a) Could meet CODASYL database interface requirements.
(b) Improved consistency and safety of programs by ensuring agreement of
arguments and dummy arguments.
(c) User defined checking can be done at compile~time further improving
of programs (e.g. the CODASYL database interface requires the
checking of (some) arguments against external "schema" information).
(d) Default argument values.
(e) Variable length argument lists, possibly.
3. Extended PARAMETER and Compile-time intrinsics. These would enable processor
parameterisation as well as pre-calculation of constant expressions.
Benefits:
(a) Precision definition at compile-time and other processor parameters -
leading to improved portability and safety.
4. Performance and Trade off controls. This is a list of features that could
be supplied by general purpose macro facilities, some of which have been
supplied in the past as independent software tools and preprocessors.
Benefits:
(a) Macro/Subroutine interchangeability. The benefits derive from removal
of the subroutine CALL and "constant conditionals" overheads (to
improve performance) (Ref. University of Colorado BIGMAC II - where
the application of this technique to a program called DAVE resulted in
50% savings in execution time.
(b) The conditional removal of macro code where 'constant' macro arguments
are supplied could reduce program size and the load size of programs.
Medium Priority compile-time features
l. User extended/defined control structures. These permit the user to create
new "control" statements in language (e.g. the user might want a "Zahn"
control structure, which is not currently part of Fortran). User extended
control structures are not vital to the language - most users can make do
with the existing standard-provided control structures and those of Fortran
8X should be adequate.
2. User extended/defined_data structures. The new Fortran 8X may provide this
facility in standard Fortran - macros would only help in the F66 and F77
case where data structures might be "modelled" by macros using COMMON
statements etc.
3. Processor Directives. There is uncertainty as to whether these should be
within the scope of macros - or whether they should be provided by some
other mechanism. X3J3 is currently considering the USING statement.
4. Acting as a preprocessor. Much preprocessing is done these days by special
purpose preprocessors. The macro facility could provide equivalent features
in perhaps a more standard way.
5. Alias names - short forms. If the length of variable names is extended to
30 or more characters, the repeated use of long names is tedious and error
prone. A macro definition or substitution by a short form name could be
an effective way of reducing the typing need.
Low Priority compile-time features
1. Extended syntax The scribe notes of meeting 71 indicate that
the ability to extend the syntax of the Fortran language in an
arbitrary way is too powerful a facility to give users and would
lead to the language becoming obscure and/or unrecognisable -
this would not help portability or many of the other objectives
of the committee.
2. Text editors These are somewhat similar to preprocessors and it
is not certain whether macro facilities will help text editors
much.
ALAN CLARKE