Minutes of BCS Fortran Specialist Group Meeting held at
BCS HQ on 19th April 1988
Present: Mike Bennett - CEGB Staff College
Mike Delves - University of Liverpool
Miles Ellis - Oxford University
Mike Geary - NAG
Dave Griffiths - SSF
Carol Hewlett - LSE
Peter Holland - SSL
Chris Lazou - ULCC
Clive Massey - Bath University
David Muxworthy - University of Edinburgh
Keith Normington - Coventry Polytechnic
Mike Nunn - CCTA
Nick Saville - ASE Ltd
Julian Tilbury - University of Salford
John Wilson - Leicester University
John Young - MOD(PE)
l. APOLOGIES FOR ABSENCE
Apology was received from Lawrie Schonfelder.
2. MINUTES OF PREVIOUS MEETING [21 January 1988]
The minutes of the previous meeting were accepted without revision.
3. MATTERS ARISING
(i) BSI Response to ANSI on Fortran 8X
The BSI committee responsible for providing the official UK response
to ANSI on the Fortran 8X draft standard had voted "No, with comments" and listed
those features which would need modification for its vote to be changed to "Yes".
However, the BCS Fortran Group was not happy with this, given that most of the
attendees at the recent "Fortran Forum" had been broadly in favour of the 8X
draft. It had been agreed at our previous meeting that the Chairman, John Wilson,
should write to BSI and CBEMA to make it clear that we basically supported the
draft but wished to make some comments on it. However, subsequent discussions
in which John was involved indicated that it would not be good for the UK to
appear split so John has written to CBEMA and also sent a mail message to the
chairman of X3J3, Jeanne Adams, pointing out that the Group was broadly in favour
of the draft and wanted ANSI to proceed with it as quickly as possible. Miles
Ellis, who attended the last X3J3 meeting, said that because the committee thought
there was no likelihood of getting BSI to vote "Yes" its comments would be dis-
regarded; therefore its response had been counter-productive. The UK was
insisting on too many things being changed, which was just not feasible, before
changing to a "Yes" vote. Chris Lazou had raised the problem of how the UK
response was formulated in the BCS Software Engineering Technical Committee and
DTI was trying to co-ordinate a more positive response to ANSI. David Muxworthy,
convenor of the ISO panel, however, pointed out that BSI was forced to vote "no,
with comments" because "Yes, with comments" effectively gets ignored in ISO
situations. His committee had tried to word its response reasonably positively
but unfortunately there had not been enough time to agree the wording. In
addition, there had been misguided information from above on what type of response
was possible to reflect his committee's views. In summary, they were in favour
but would like to see certain small changes.
4. BCS BUSINESS
Fortran Forum
A statement of accounts had now been received from BCS showing a surplus
of £784 on the "Forum" but did not include reimbursement of speakers'expenses.
There might be further income to the Group from the sale of spare copies of the 8X
draft. Net final profit was likely to be about £500.
Specialist Groups Management Committee
A report has been drafted advising on how to set up a new BCS specialist
group or maintain an existing one.
Charter Engineer Status
This new membership qualification is being developed on the expected
timescale.
AGM
There being no other nominations, the Chairman (John Wilson), Vice-
chairman (Chris Lazou) and Treasurer (Miles Ellis) were re-elected unanimously.
John Young was elected Secretary as successor to Mike Nunn, who did not wish to
stand again. The Chairman proposed a vote of thanks to Mike for his many years
work in the post.
The Treasurer presented the report detailed in Appendix A. Once again
the Group has asked BCS for an allocation of £600, although we have spent only
just over £200 during the year, partly because speakers at our meetings have
never asked for expenses. We had also saved money by no longer paying a fee for
ANSI observer status (which allows a copy of X3J3 minutes - not thought worthwhile
given that we were receiving excellent reports on the progress with 8X from those
Group members who regularly attend XSJ3 meetings).
From the Treasurer's financial report it can be seen that our financial
affairs are in a healthy state with the order of £2,000 in the bank. Miles
Ellis suggested this gave us a certain amount of flexibility in arranging future
events. Chris Lazou thought it gave us opportunity to set up a few trial evening
meetings, we had enough funds now to hire rooms for such and reimburse speakers.
This would give the Group greater visibility. Suggestions for talks are invited
from members; one from Chris is to explain in more detail some of the new features
in 8X.
We have about 15 copies of the 8X draft left over from "Forum" which we
can now offer for free.
ISO Situation
David Muxworthy reported that the ISO public review of the Fortran 8X
draft closed at the end of January. The international voting resulted:
"Yes, without comments" - 7
"Yes, with comments" - 1
"No" - 6
The "No" voters were Canada, France, W Germany, Japan, UK and USA. Reasons for
"No" votes included:
Canada - Wanted bits, significant blanks, pointers
France - Language too big
- Wanted significant blanks, bits, pointers
- Basically wanted 8X to be F77 plus a few "extras"
W Germany - Wanted bits, pointers
- Wanted stream I/O in long term and variable length character strings
Japan - Rejected draft because it has not catered for Japanese character set
USA - "No" vote was procedural because further changes to the draft were
still to be incorporated
X3J3 Position
Miles Ellis, who regularly attends X3J3 meetings, said that the committee
has been developing a list of changes which they realise will need to be applied
to the 8X draft once the review period is over. A new document, mostly with
editorial changes, will be produced. The committee is building up a database of
all the points received during the review. Sub-groups within XSJ3 will be allo-
cated to deal with them. So far comments have been received from 400 individuals
and these will be considered at coming meetings. Under X3J3 rules any change to
the draft needs a 2/3 majority of those voting. One general problem is that for
some features, eg generalised precision, most users do not want but the minority
that do are exceedingly keen for them.
There will be an ISO working group discussing 8X this September in Paris -
anyone wishing to attend should contact David Muxworthy to be registered as an
accredited delegate. John Wilson put forward the idea that our Group could sponsor
sending someone regularly to ISO meetings (yearly) but it was for members to
decide whether this was a sensible way to spend the Group's funds. Keith
Normington suggested it required tabling on the agenda for the next meeting and
given appropriate discussion.
John Reid (Harwell) has supplied a detailed report on the latest X3J3
meeting held at Urbana, which appears in Appendix B.
6. ANY OTHER BUSINESS
The Secretary pointed out that a membership renewal form would be sent
out soon to every member. Non-BCS members would be charged £5 to cover cost of
newsletter and administration costs for the year 1988/89.
The Group would welcome suggestions from members on topics and speakers
for future meetings. Provisional dates for these are:
Thursday, 28 July 1988
Thursday, 6 October 1988
Thursday, l9 January l989
Thursday, 27 April 1989 (including AGM)
In the afternoon Professor Mike Delves gave an entertaining talk comparing
Ada with Fortran. This was followed by a lively account by Nick Saville, member
of our Group and a software writer by profession, giving his own experiences in
the same area. Summaries of both appear in Appendix C.
8. DATE OF NEXT MEETING
The next meeting of the Group will take place on Thursday, 28 July 1988
from lO.3O am to 4.00 pm at BCS HQ, Mansfield Street, London.
Mike Nunn
Secretary
BCS Fortran Specialist Group
3 June 1988
Appendix A
British Computer Society Fortran Specialist Group
Final Accounts 1987-88
A) Internal Account
Budget Allocation for 1987-88 600.00
Expenditure
Minutes (July) 62.13
(Sept) 46.28
(Dec) 69.32
(Feb) 21.84
(Apr) 14.37
Catering (Oct) 17.50
(Apr) 25.00
Speakers
Expenses (Apr) 26.15
Postage of
Standards 17.60
300.19 300.19
Surplus returned to HQ 299.81
B) Current Account
Balance at 30/4/87 373.05
Income
Subscriptions 10.00
Newsletter
Sponsorship 80.00
Surplus from Fortran
Forum 550.14
Transfer of deposit
a/c 1027.92
1668.06
Expenditure
Meeting expenditure 27.00
Net surplus 1641.06 1641.06
Provisional Balance at 30/4/88 2014.11
C) Deposit Account
Balance at 30/4/87 961.83
Interest 66.09
Balance at 29/4/88 1027.92
Transfer to current a/c 29/4/88 -1027.92
ACCOUNT CLOSED 29/4/88
D) Fortran Forum - November 1987
Income
Delegate Fees 7800.00
Sale of draft
standards 360.00
8160.00
Expenditure
Printing of draft
standards 2040.00
Hire of room etc. 1714.25
Misc. Expenses 893.81
BISL fee 2633.50
Speakers' travel
expenses 328.30
7609.86
Nett Surplus to Current Account 550.14
T.M.R. Ellis
Treasurer
15th June, 1988.
To: Fortran Forum, BCS, NAG, etc.
From: John Reid
Date: 16 May 1988
Subject: X3J3 meeting in Urbana
Note: This is a personal report on the meeting and in no sense does it
constitue an official record of it
1. Summary
For the moment, the Committee is in deadlock. All formal proposals
require that at least half the Committee members (21) vote 'yes' and
that there are at least twice as many 'yes' votes as 'no' votes. We
need a proposal (or rather set of proposals) that will not be
unacceptable to a third of the members because it removes too much of
the present language or unacceptable to a third because it does not
simplify the language enough.
The Chairman has charged members to prepare proposals for the next
meeting that aim for acceptability to two-thirds of the members. I
will be preparing one such proposal jointly with Brian Smith of
Argonne.
2. Public Comments
377 letters from the public have been formally registered, a 4 inch thick
pile of paper. The quality varies enormously, from a duplicated DECUS
letter to long letters from people who had clearly read the draft
carefully. Three quarters of them were available before the meeting
and the remainder were copied at the meeting. The recurring themes
are:
(l) The language is too complex.
(2) Dislike of the deprecation of COMMON and EQUIVALENCE.
(3) Wish for INCLUDE, bits, and (to a slightly lesser extent) pointers.
There was an alarming tendency by some Committee members to count the
letters as if they were votes. For example, the number of letters in
favour of modules was compared with the number that suggested their
removal. A simple count does not take into account how carefully the
writer has considered the topic and those in favour of a feature may
say nothing about it simply because they do not know that it under
threat. I think we must do our best to respond to themes, but also
take good ideas into account even if suggested by only one person.
3. Responding to public comments
The Chairman hoped that, by the last day of the meeting, the Committee
would agree on those changes that have a major impact on the
language. Most of the first two days were devoted to subgroup time for
considering such changes. Roll-call members-only straw votes were
taken on the following issues:
1a. Amend Section 1.6 and Appendix B to remove the concept of
deprecation (28-3-4).
lb. Integrate deprecated features with new features (8-15-11).
2. Add pointers (2l-6-9).
3a. Add an intrinsic bit data type (14-l3-8).
3b. Add bit intrinsic procedures or an intrinsic bit data type or
both (29-1-5).
4. Add multibyte characters (11-15-10).
5. Remove RANGE and SET RANGE (28-2-5).
6. Remove ALIAS and IDENTIFY (23-5-7).
7. Simplify generalized precision (29-2-3).
7a. Simplify generalized precision to having a single parameter with
values 1 and 2 for single and double, respectively (l2-15-6).
8. Add parameterized integers (6-15-14).
9. Add vector-va1ued subscripts (16-16-3).
10. Add stream I/O (12-11-12).
11. Add derived-type I/O (5-27-3).
12. Eliminate MODULE/USE (7-22-6) .
12a. Simplify MODULE/USE (18-9-5).
13. Add INCLUDE (26-8-1).
14a. Eliminate user-defined operator overloading( ll-2O-4).
14b. Eliminate user-defined procedure-name overloading (10-14-11).
Based on these votes, the Technical Change Review Group suggested the
following package:
1. Remove the concept of deprecation.
2. Add pointers.
3. Add bit intrinsic procedures.
4. Remove RANGE and SET RANGE.
5. Remove IDENTIFY and ALIAS.
6. Simplify generalized precision.
7. Add INCLUDE.
However, when the Committee was asked how it would vote on a revised
draft whose major changes consisted of these items, the vote was
15-21-1. Those voting 'no' do not object to the items in the list, but
they want a further simplification and are concerned about the
mismatches and duplications between new and old features.
4. Presentations by commentators
All commentators are being invited to attend a meeting and address the
Committee. This time we had presentations by John Swanson of Swanson
Analysis Systems, Inc. and Loren Meissner of the University of San
Francisco.
John Swanson maintains an engineering analysis program of about
275,000 lines on 35 different systems. He is particularly concerned
about portability, reliability / quality assurance, and run-time
performance. He feels that Fortran 8x is too complex, which is likely
to lead to a long delay before sufficiently reliable compilers are
available on sufficiently many systems; also that we have not built on
current practice re bit functions, IEEE standards, COMPLEX*l6, and
INCLUDE. He likes in-line comments, long names, DATE_AND_TIME,
IMPLICIT_NONE and zero-sized arrays.
Loren Meissner supports the present overall size of the language but
feels that both bits and pointers are needed; also that significant
blanks should be introduced with the new source form - this is not
something that can wait for the next revision.
5. Procedural matters
For the first time since I joined the Committee, the
minutes were voted up by a non-unanimous vote. The members
from Harris and Boeing believed that something was missing
from the scribe notes although they were not able to say
what it was nor were willing to negotiate a change of
wording. It was, however, unanimously agreed that the
formal decisions were recorded correctly.
The IBM delegate objected to the straw votes that I have described in
Section 3 because they were prepared during the meeting and not
circulated on paper at least two weeks ahead. He was over-ruled by the
Chairman because no formal decisions were being made; rather the
committee was trying to judge its own mood on the issues e very
necessary with such a large committee. It is my opinion that not
taking these votes would have further delayed the standard by a whole
meeting (i.e. another 3 months).
I am pleased to report that these formal moves have not destroyed the
friendly spirit of the Committee at informal gatherings.
6. Other matters
As has been the case at several recent meetings, we voted up a fair
number of editorial changes, including a substantial revision of the
glossary (largely my work). The a only non-trivial proposal passed is
to disallow reference to a data object in a module if its type is
private or to a module procedure that has a dummy argument whose type
is private.
7. New members
The Committee has a serious problem over membership. At the next
meeting there will be eight members whose first meeting was in
November 1987, February 1988 or May 1988. The trouble is that these
new members are not familiar with the reasons for things being the way
they are and do not feel that they 'own' the document. Several
suggestions being made would reverse the policy that has been in
operation for the last five years and return to where the Committee
stood some eight years ago. I am not saying that all our decisions are
correct and that we should not alter those that give rise to wide
public disquiet. But I am worried about unstable oscillations of
policy resulting in e no standard being agreed. For example, we might
make a big reduction in the size of the language now, go out for
another round of public comments, and receive a flood of complaints
about being too conservative.
We are not helped by ANSI having relaxed the formal rules
slightly. Now anyone willing to attend meetings, not necessarily
knowing anything about Fortran, automatically becomes a member after
attending one meeting as an observer (except that each organization is
limited to one member).
8. Next meeting of X3J3
The next meeting of X3J3 will be in Jackson, Wyoming, 8-12 August. The
premeeting deadline is July 4th.
"ADA VERSUS FORTRAN"
Talk by Professor Mike Delves (Liverpool University)
Mike Delves believed that the major achievement of Fortran 8X will be
improving expressiveness compared with F77 whilst retaining compatibility. His
area at Liverpool University was originally an Algol 68 shop and switched to
Ada as the only reasonable substitute.
Mike claimed that Fortran had developed as a language that could achieve
power but with reasonable tidiness. However eleven years for a revision cycle
was too long and Fortran 8X was arriving too late. By comparison Ada compilers
already existed and were reasonably efficient. Fortran 8X, of course, had the
big plus going for it that its user base was very large. In the case of Ada he
believed it had passed its break even point and will now take off.
Was the F8X standard too large? In his view the answer was "No"; there
should be no efficiency problems in implementing the features 8X provided. Was
it hard to learn? That depended on the teacher. However, he did feel that Ada
was much tidier. It had a tightly defined upgrade path with a new version scheduled
every five years - the original language appearing in 1983. However, he had to
admit that the next version due this year had been cancelled! An advantage held
by Ada was that its language standard was tightly defined whereas F8X has no
defined tools for checking conformance. Ada was quite cheap now, with compilers
available for PCs for as little as £120.
Items missing in Ada compared to Fortran included "complex", "sin or cos",
array handling (but this was a virtue in just defining a bare language - in fact
Ada was no bigger than F8X). Ada also offered very little I/O. Its elementary
functions, he believed, were better designed than Fortran.
Analysing merits in more detail:
Ada better - power, orthogonality
Fortran better - extensibility, floating point, I/O, legibility of
definition document
Overall there was not much to choose between them. However, at Liverpool they
had not really become fans of Ada.
Multi-tasking was an area of missed opportunity for F8X. Ada tasks tend
to be rather verbose but Mike has not found any real problems in using this feature
However real-time programmers, for whom the language was designed, have been
reporting problems with details such as priorities in tasking mechanisms.
Hopefully some language modifications on the way should cater for these criticisms.
He could report that Ada generics work very well. Details of the syntax
are quite convenient. What are Ada pointers like? Answer "so-so". I/O was more
difficult in Ada than Fortran, one could only deal with one object at a time.
Generally there was no problem in getting Ada code running at least as
fast as Fortran. The latter could be written quickly but this was counterbalanced
by the fact that it took a lot longer to get programs working. The power in Ada
made it easier to write applications than Fortran. He thought Ada would succeed
because of DOD support.
"EXPERIENCES WITH ADA AND FORTRAN"
Talk by Nick Saville (consultant professional software writer)
Nick Saville has had very many years experience working as a contract
programmer. His first language (other than assembler) was Algol 60. Soon after-
wards he learnt COBOL, a language which was to generate him more money for less
work than any other during his programming career! He has also written in BASIC,
a very boring language, which has got even worse over the years. More recently
in 1984 he learnt C from the white book and then taught himself C for fun. With
this much self-learning experience Nick can defend the thesis that if any language
is difficult to learn from a book then there is something very peculiar about it.
Eighteen months ago Nick thought it would improve his mind to learn Ada,
which is apparently the language of the future. As he could not afford a
course he bought two books. Neither turned out to be any good so he then got hold
of the Ada standard itself and the dictionary mentioned in the Standard. For
about six months he devoted several hours each night trying to learn Ada. In
particular he looked for its supposed "top-down" syntax but couldn't find it.
Nick became impatient with his slow assimilation of the language and it occurred
to him that lots of people write programs in any language without knowing all of
it. He arranged with York University to buy some machine time on their VAX and
proceeded to write a general purpose macro expander in Ada, something he had
implemented previously in several other languages.From this experience he believes:
(l) Ada is definitely not an easy language to learn - and if Fortran 8X
isn't either then this should be of major concern.
(2) Ada compilers will be of a very small family of compilers written in a
certain way (University of Karlsruhe).
Mike Delves considered that the language definition document was not a good
starting point for learning a language. Chris Lazou said that whereas Algol 6O
and 68 were very efficient for small programs they lost this efficiency with large
ones; in Fortran by comparison its subroutine mechanisms worked more efficiently.