MINUTES OF BCS FORTRAN SPECIALIST GROUP MEETING
HELD AT BCS HQ, 13 MANSFIELD STREET, LONDON
ON 9 DECEMBER 1985
Present:- J L Dyke - HRC
Miles Ellis - Oxford University
Bill Flexner - Retired
Mike Geary - NAG
D T Griffiths - SSF
David Harris - Alpha Comp Ltd
J P Holland - SS(E)L
Carol Hewlett - LSE
Chris Lazou - ULCC
Karen Ma - British Telecom
Brian Meek - King's College, London
K Normington - Coventry Polytechnic
Mike Nunn - CCTA
E G Reilly - B MT
T Van Raalte - MOD (PE)
N R Saville - Private Consultant
John Steel - QMC
David Vallance - Salford University
Steve Watkins - UMIST
John Wilson - Leicester University
John Young - MOD (PE)
Addresses:-
Chairman: John Wilson
Computer Centre
University of Leicester
LEICESTER LE1 7RH
Tel: 0533 554455 ext 9137
Vice-Chairman: Keith Normington
Computer Centre
Coventry (Lanchester) Polytechnic
COVENTRY CV1 5FB
Secretary: Mike Nunn
CCTA
Riverwalk House
157/161 Millbank
LONDON SWlP 4RT
Treasurer: John Dyke
Huntingdon Research Centre
HUNTINGDON PEl8 6ES
l. Apologies for Absence
Apologies were received from David Muxworthy, Dennis Parkinson,
John Reid and Lawrie Schonfelder.
2. Minutes of Last Meeting [16 September 1985]
2.l. The Chairman, who was abroad at the time of the last
meeting, expressed his thanks to the Vice-Chairman,
Keith Normington, for deputising for him.
2.2. Corrections:-
Page 1 "Mike Ellis" should be "Miles Ellis."
Page 3 "BSC Study" should be "BCS Study."
Page 5 "Chris Laxou, believed Frotran" should be
"Chris Lazou, believed Fortran."
3. Matters Arising
3.1. Draft British Standard "Method for Specifying Requirements
for Fortran Language Processors"
Following our September meeting, the Secretary had written
on behalf of the Fortran Specialist Group expressing
dissatisfaction with the limited opportunity for members
to comment on the new draft. The reply received from the
Secretary of the BSI OIS/5 Committee was discussed, but was
generally considered to miss the point on some of our complaints.
As a member of OIS/5, Brian Meek put forward the following views:-
(i) Due to limited resources, BSI staff are only
announcing that new Standards are available
for public comment via "BSI News."
(ii) Those OIS/5 members who also attend our Group
did not know that the draft had been released
for public comment (it appeared during the
holiday period) and so could not let us know.
It had been delayed at BSI HQ.
(iii) He thought it was still not too late for comments
to be considered. They should be passed direct
to David Muxworthy, CAST, Edinburgh University,
l8 Buccleuch Place, Edinburgh, EH8 9LN.
3.2. BCS Standards Meetings
A meeting of representatives of the different BCS Specialist
Groups was taking place on December l6 to appoint nominees
for the National Computer Users Forum (NCUS) and also determine
a more coherent BCS policy on language standards than in the past.
On February 28 there will be a BCS meeting open to other
members to discuss why standards matter, the activities of BSI
and BCS attitude to standards.
Brian Meek felt that all Specialist Groups should be aware of,
and participate in, standards activities. In the case of the
Fortran Group we were already doing so - even without BCS funding!
He also pointed out that the BSI Fortran panel will be reconstituted
to provide the official UK view on "Fortran 8X" to X3J3 and will
expect the BCS Fortran Specialist Group to submit a response.
[Therefore all members of this Group are invited to send
comments to the Secretary for discussion and possible endorsement
by the whole Group as input to BSI and X3J3. This in no way
precludes individuals from sending comments direct to X3J3 who -
by the constitution must consider and respond to all comments
received.]
The release of the final "8X" draft for public comment had
been slightly delayed and it was not quite clear when this
would now be. However, it is the intention of your Committee
to organise another "FORTRAN FORUM" to discuss the draft soon
after it is released, probably early in 1987.
3.3. Letter from Gregory Aharonian - "Lets Kill Future Fortrans"
There was a lively discussion provoked by the letter received
from Gregory Aharonian in Massachusetts who wanted to kill off
Fortran. Some of the views expressed by members were:-
Nick Saville - APL was dramatically inefficient and also
unreadable;
- C allowed users to do very dangerous things;
- Ada was unlikely to supersede Fortran;
- most of the languages quoted were far less
efficient than Fortran;
- on first sight of the limited I/O in Pascal
he was quite shocked.
Keith Normington - Fortran had a certain style of its own
and had the advantage of not trying to do too
clever things;
- C by contrast had the disadvantage of being
for clever programmers;
- we should tell Mr Aharonian that we had
considered his letter, but it was not feasible
just to abandon Fortran and legislate it out
of existence;
- it was becoming fashionable in the academic
community to 'knock' Fortran.
Chris Lazou - Most scientific work had always and would
continue to be written in Fortran;
- Fortran had masses of software available
which was not the case with most other languages
- 85% of users at his own site (ULCC) use Fortran;
- Fortran would continue until there was a
programming revolution.
A letter had been received form Professor Dennis Parkinson (QMC)
challenging many of the assertions in G Aharonian's letter (see
4. BCS Business
4.1. The Treasurer had asked BCS for a budget of £500 for
the Fortran Group for 1986/7. There were suggestions that
we should ask for more.
4.2. A letter had been received from the BCS Newcastle Branch
(see appendix B) announcing a one day conference in May and
seeking representatives from Specialist Groups to give presentations.
The Chairman said that he understood that David Muxworthy would
give a talk on behalf of the Fortran Group.
4.3. At a recent meeting of the BCS Specialist Groups Board
a uniform system for sending out mail to Group members was
agreed.
5. Fortran Forum
5.1. John Reid (Harwell) who regularly attends X3J3 meetings
said that the Chairman, Jeanne Adams, was not optimistic now
that the draft "8X" Standard would be released for public
comment before the end of 1986. Therefore it would be sensible
to have our Forum soon after that happened, i.e. probably early 1987.
5.2. Chris Lazou, Chief Organiser of "Fortran Forum 85"
had just received the accounts from BCS Conference Section and
they showed that the event had produced a profit of £1659 for
the Group. The Treasurer would open a deposit interest bearing
account for the money which would be used to help set up the
next "Forum". Chris Lazou believed that even though there would
be no "Forum" in 1986, we should organise some other event to
keep up the momentum which "Fortran Forum 85" had generated.
6.1. None of the regular UK attendees of X3J3 meetings was
present on this occasion, but John Reid had submitted a written
report (see appendix C). The main thrust of the latest meeting
at Tulsa in November, ha been that it was decided that the
draft standard was not yet ready for the postal ballot of X3
members which would be needed before it could be released for
public comment. Most of the work was in trying to clean up
details rather than introduce new features. The Chairman read
out the key features of John's report for the benefit of those
attending. [Since the meeting John has kindly provided a
report on the subsequent X3J3 meeting at Sunnyvale in January -
see appendix D].
7. Any Other Business
7.l. NATLAS - National Testing Lab (NPL based) has been set
up as a Group to devise standard testing methods for proving
programs.
7.2. After some discussion the Group decided that there
should be a regional meeting during the coming year. It
was decided that Birmingham or Coventry was the best choice
for this and it was allocated for the September meeting.
7.3. It was suggested that it would be interesting for the
Group to visit a site of particular interest and meet its
Fortran users on the day of a future meeting. It was agreed
that the Secretary would approach European Weather Centre at
Bracknell to see if they could arrange a tour for the Group
together with the opportunity to talk with their Fortran
users. It was hoped that this could be set up for June.
8. Date of Next Meeting
The next meeting of the Group would take place at 10.45 am on
Monday l7 March at BCS HQ, 13 Mansfield Street, London. It would
include the AGM. In the afternoon we would have three individual
speakers talking about floating point accuracy and numerical precision
in Fortran. They would be Mick Pont (NAG), Chris Cartledge (Salford
University) and Lawrie Schonfelder (Liverpool University).
9. Talk "Using DEC Computers in the Field of Dynamic Simulation"
In the afternoon David Harris of Alpha Comp Ltd gave a talk on the
use of DEC computers in the field of dynamic simulation. A summary of
this appears in appendix E.
Mike Nunn
Secretary
February 1986
QUEEN MARY COLLEGE
UNIVERSITY OF LONDON
DAP SUPPORT UNIT MILE END ROAD
COMPUTER CENTRE LONDON E1 4NS
Director J P Brandon M Sc Tel 01-980 4811
Head of Unit Professor D Parkinson
2 December 1985
Mr M Nunn
CCTA
Riverside Walk
157 Millbank
London SW1P 4RT
Dear Mike,
You asked for comments on the Aharonian note - I am sure that it will
produce heated comments from the FORTRAN group - enclosed, please find
my own reactions.
Regards.
Yours sincerely,
Professor Dennis Parkinson
Head - DAP Support Unit
P.S. Unfortunately I cannot attend the 9 December meeting owing to other
commitments.
Enc.
c.c. J Steel
H Liddell
A Wilson
FORTRAN FUTURE
D. PARKINSON
DAP Support Unit
Queen Mary College
University of London
Gregory Aharonian's paper "Let's Kill Future Fortrans" is yet
another salvo in the computer language war. A basic premise of
the paper is that FORTRAN can be killed by actions of committees.
FORTRAN will only die as the result of market forces, that is
when no manufacturers see sufficient market demand to justify the
provision of FORTRAN compilers.
The cessation of activities by ISO/ANSI in developing new
standards would probably be welcomed by 75% of the FORTRAN user
community who like the rest of the community, do not really like
change. Most of the FORTRAN community would be happy to stay with
a fixed language with its existing compilers etc. FORTRAN would
then only die out by a combination of:
a) Retirement of current programmer base
b) Lack of recruitment into the FORTRAN users community,
and
c) Non-implementation of FORTRAN compilers on new computer
hardware systems.
Currently, no computer manufacturer who wishes to sell products to
the scientific/engineering market dare not offer a FORTRAN
compiler.
Demand for FORTRAN may wane if there are available alternative V-
languages which:
a) are capable of producing programs of better, or
comparable efficiency to FORTRAN,
b) Offer a sizeable increase in programmer productivity
relative to FORTRAN, and
c) are capable of handling both large and small programs
as well as FORTRAN.
The majority of the discussions of the relative merits of
languages, FORTRAN-PASCAL-C-BASIC etc. are not very constructive.
For small programs the best language is that which the User feels
most at home with, which is probably the first language they
learnt. Each language has some area of application in which it is
better than the others, but it is a naive commentator who would
claim that one language is best for all types of applications.
If the standards community want to kill FORTRAN then they should
proceed as follows:
i) Introduce updates to the standards more frequently,
ii) Ensure that the new standards almost incorporate
the last one as a subset
iii) Encourage manufacturers to add further extensions to
the language e.g. BLAS, but do not actually
incorporate these in the standard, and
iv) Ignore the fact that programming languages are
first and foremost tools to allow users to
solve problems and spend so much effort on making
the tool look pretty, that the sharpness of its
cutting edge is damaged.
Parallel Constructs
Aharonian does not see the need for extending FORTRAN to include
parallel constructs suggesting that APL is used. This suggestion
seems somewhat at odds with the suggestion that for other
operations, C is the language to which the FORTRAN community
should switch. Is the suggestion that C and APL should be somehow
combined?
There is a touching faith in the ability of programs such as
Parafrase to bring out parallelism in existing programs. Tools
such as Parafrase, do provide a part solution to the "dusty
FORTRAN deck" problem, but to suggest that their existence is a
reason not to provide parallel language constructs is ridiculous.
At a recent presentation of the array extensions to FORTRAN, I sat
alongside a veteran FORTRAN programmer who totally misunderstood
the point of it all, but just kept muttering, "I can do all that
with a DO loop!". Indeed you can, unfortunately (?) do almost
anything you want with FORTRAN - it's just often complicated.
Consider the following, not untypical, task which arises in
problem areas such as image processing and solution of partial
differential equations. Given an array of variables
Xij i = 1...n, j = 1...m, compute a new array
Yij i = 1...n, J = 1...m
such that Yij = Xi-1,j + Xi+1,j + Xi,j+1 + Yi,j-1
where X0,j ≣ Xn,j Xi,0 ≣ Xi,m i = 1...n
Xn+1,j ≣ Xi,j Xj,m+1 ≣ Xi,1 j = 1...m
In non array FORTRAN this problem could be programmed as follows:
REAL INTEGER X(N,M),Y(N,M)
INTEGER N,M,I,J
C
C DO NON-EDGE POINTS
C
DO 10 I = 2, N-1
DO 1O J = 2, M-1
Y(I,J) = X(I-1,J)+X(I+1,J)+X(I,J-1)+X(I,J+1)
1O CONTINUE
C
C DO FIRST AND LAST COLUMN
C
DO 20 I = 2, N-1
Y(I,1)=X(I-1,1)+X(I+1,1)+X(I,2)+X(I,M)
Y(I,M)=X(I-1,M)+X(I+1,M)+X(I,1)+X(I,M-1)
2O CONTINUE
C
C DO FIRST AND LAST LOOPS
C
DO 30 J = 2,M-1
Y(1,J)=X(N,J)+X(2,J)+X(1,J+1)+X(1,J-1)
Y(N,J)=X(N-1,J)+X(1,J)+X(N,J+1)+X(N,J-1)
3O CONTINUE
C
C DO ALL CORNERS
C
Y(1,1) = X(N,1) + X(2,1) + X(1,2) + X(1,M)
Y(1,M) = X(N,M) + X(2,M) + X(1,1) + X(1,M-1)
Y(N,1) = X(N-1,1) + X(1,1) + X(N,2) + X(N,M)
Y(N,M) = X(N-1,M) + X(1,M) + X(N,1) + X(N,M-1)
This is difficult to do accurately! Indeed, I expect that some
eagle eyed reader may well discover an error (I made 6 corrections
to the first draft!).
The array extension in FORTRAN 8X - use the shift functions and
reduce the coding complexity to:
REAL X(N,M),Y(N,M)
INTEGER N,M
Y = CSHIFT(X,-1,1)+CSHIFT(X,1,1)+CSHIFT(X,2,1)+CSHIFT(X,-2,1)
The reader may think that I have cheated in picking a special
example but in reality I have been kind to the Fortran example.
In practical examples the probability is that the fragment would
be part of an iteration scheme. The programmer would want the
values of X to be overwritten by the new iterates Y. In this case
the 8X FORTRAN would simplify to:
REAL X(N,M)
INTEGER N,M
X=CSHIFT(X,-1,1)+CSHIFT(X,1,1)+CSHlFT(X,2,1)+CSHIFT(X,-2,1)
The syntax of the CSHIFT functions is not pretty but the decrease
in programming complexity is spectacular. If the reader still
doubts the advantages they should modify the requirement to
include the restriction that the iteration should only be
performed if Xij is greater than say 2.0.
In 8X FORTRAN the code simply becomes:
WHERE(X.GT.Z.O)X=CSHIFT(X,-1,1)+CSHIFT(X,1,1)+CSHIFT(X,2,1)+CSHIFT(X,-2,1)
The coding of this in FORTRAN 77, C, PASCAL, LISP or even APL is
left as an exercise for masochists.
SUMMARY
FORTRAN-77 is not beautiful - but neither is C, PASCAL, ADA etc.
They are all low level languages requiring the user to waste much
effort in specifying irrelevant information. The purpose of a
computer language is to enable programmers to create programs
which are correct, maintainable and efficient.
Modern economics also requires that the resulting programs are
produced efficiently and are transportable. Papers such as that
of Aharonian which suggest that these ends can be achieved simply
by abandoning, say, FORTRAN for C are not helpful.
Two possible futures for FORTRAN can be predicted.
1) Evolutionary - a gradual change 88-99 etc, which will
evolve the language in such a fashion that eventually
it becomes just a regional dialect of a widespread
language.
2) Extinction - due to lack of enthusiasm of the younger
generation in following the habits of their predecessors.
If we try to draw an analogy with spoken languages, we
see that this can be a long drawn out process. Attempts
by authorities to stamp out languages such as lrish,
Welsh, Cornish etc. have not been successful.
The idea that we can change everyone to speaking some
theoretically better language (Esperanto?) appears to be pure,
wishful thinking.
The British Computer Society
PLEASE REPLY TO
Mr. R.S. Burgess
Chairman, Newcastle and District Branch
Newcastle upon Tyne Polytechnic
School of Computing and Informatics
Northumberland Building
Northumberland Road
NEWCASTLE UPON TYNE NEl 8ST
Dear Mr. Nunn 15 November 1985
Proposed One-Day Conference in Newcastle
Speakers from the BCS Specialist Groups
I am writing to you as Secretary of one of the British Computer Society's
Specialist Groups. The committee of the Newcastle Branch of the British
Computer Society is proposing to organise a one-day conference with
speakers from the Society's specialist groups for members of the
Society in the NE of England.
One of the criticisms made of the Society's activities, by members in the
NE, is that the vast majority of the specialist groups are based in the
London area, and it is difficult and expensive for them to attend
their meetings. This proposed conference is an attempt to partially answer
that criticism by bringing some of the specialist groups up to the NE.
The tentative date suggested for the conference is Friday, 30th May, from
9.30 am to 4.00 pm. It is proposed to organise two parallel sessions
involving 8 different presentations in all, each presentation lasting about
1 hour 15 minutes (including time for questions and discussion).
The topic for each presentation at the proposed conference would be left
to the individual speaker providing that firstly, it related to specialism
of the specialist group he/she was representing and secondly, it was a
topic likely to be attractive to a significant number of members in the
region. It is also proposed to charge a minimum conference fee to attendees
who are members of the Society, enough to cover hire of accommodation,
visiting speakers' expenses and refreshments. This means that we do not
intend to offer visiting speakers a fee!
I do hope that your specialist group will feel able to contribute one
speaker for such a conference. I would appreciate the early consideration
of this proposal by yourself and your group and an early indication as to
whether your group would be willing to provide a speaker for the proposed
conference.
Yours sincerely
R.S. Burgess
Chairman, Newcastle and District Branch
copy to your Chairman
To: BCS, NAG, FORTEC, etc.
From: John Reid
Date: 16 November 1985
Subject: Report on X3J3 meeting at Tulsa, 11-l5 November 1985
Note: This is a personal report of the meeting and in no
sense does it constitute an official record of it.
References: [1] 97(*)JKR-2 Deletion of vector-valued sections.
[2] 97(*)ALM-1 RANGE proposal
[3] 97(l4)JKR-9 Conformance
l. Summary
Once again the main thrust of the meeting was detailed work on
the draft standard, S8. The editorial subgroup met for three days
before the meeting. A number of detailed proposals needed for the
standard, were passed. I will not describe them here. At the end of
the meeting the chairman asked whether the document was ready for a
postal ballot of X3J3 and the committee thought not (3-29-l). It
still needs a lot of polishing, but the committee is quite optimistic
(20-3-11) that it may be ready after the January meeting. If this is
so, the chairman envisages two more meetings processing "no" votes and
forwarding the document to X3 next summer.
A major proposal, ranging of arrays, was passed (see section 10)
without much dissension. However there was considerable discussion of
result typing (section 4) and array argument compatibility (section
5), both of which were resolved, and of the combinatorial explosion
that passed-on real attributes can cause (section 3), which looks as
if it may be resolved at the next meeting. The chairman is trying
hard to limit discussion to problems associated with features that
have been passed, rather than making changes or additions.
2. Deletion of vector-valued sections
I proposed [l] the deletion of vector-valued sections and their
replacement by GATHER and SCATTER intrinsics. This was on behalf of
the task group set up in Urbana to explore reducing the size of the
language. My proposal failed last year when I moved it as a personal
proposal and it failed this time too (7-6-15, l0-11-5, 6-14). The
counter arguments centred on the greater clumsiness of the use of
intrinsics and the problem that the equivalent of
A(VECTOR)=B
is
A=SCATTER(A,B,VECTOR)
which will not be a valid assignment if the elements of A that are not
selected are undefined.
3. Passed-on precision
It was decided (18-7) to remove the interpretation that when
more than one dummy argument is declared with passed-on precision in
the same statement, they all have the same precision. This rule is
unnatural and insufficiently general to link real and complex
arguments. The intention was to move another proposal that would
provide an alternative linking facility, but the syntax proposed was
not liked. There was much concern at the possible "combinatorial
explosion" if there are several arguments with independent passed-on
precisions (if there are n arguments and 3 precisions, 3n versions are
involved). Carl Burch proposed the ruthless cure of interpreting all
passed-on precisions as being identical, but did not move it because
he felt that it was too inflexible. George Paul suggested using the
CASE syntax to enumerate the versions wanted. This appears to meet
the requirements, and Geoff Millard and I will prepare a proposal for
the next meeting.
There was some question as to whether the committee wishes to
retain passed-on precision, but a straw vote on deletion was negative
(8-l6-8).
4. Result typing
There was much debate over the syntax for recursive functions.
The obvious extension of Fortran 77 may lead to an ambiguity for a
recursive array-valued function. About eight alternatives were
considered, all of which had one disadvantage or another. The rules
in S6 work, but were not correctly transcribed to S7. They provide a
RESULT clause to rename the result and do not permit the new name to
be typed. Eventually the argument "if it ain't broke, don't fix it"
seemed to win the day and the S6 rule was reaffirmed (l8-7).
5. Array argument compatibility
I proposed requiring an explicit interface when calling
procedures with assumed-shape dummy arguments. This will permit an
implementation to keep all other kinds of dummy arrays contiguous,
thereby allowing calls to object modules (perhaps written in another
language) that require this. Implementations that use a "dopevector"
convention do not need the restriction, but it is mild. I hope that
libraries will make their interfaces explicit, anyway, so that calls
to library routines are checked by the system as for intrinsics at
present. After much debate, including a three-hour evening session,
the proposal passed (14-12).
6. Conversion none
The Bonn ISO meeting requested a CONVERSION NONE declaration,
which would mean that no automatic intrinsic type conversion takes
place within expressions or across assignments. The idea was received
sympathetically (20-4-9) and a subgroup was asked to look at it
further.
7. Deprecation of automatic implicit typing
I proposed the deprecation of automatic implicit typing so that
in the long term the safer IMPLICIT NONE would become the default, but
this did not pass (6-18).
8. Deprecation of real and double precision DO indices
My proposal to deprecate real and double precision DO indices
passed (17-3).
9. Input-output proposals
Jim Matheny's proposal to allow OPEN for an internal file was
accepted (22-0).
His long-standing proposal for PROMPT= on read statements to
terminals passed (16-6).
l0. Ranged arrays
Alex Marusak's proposal [2] on ranging arrays passed (19-5).
This has been wanted by the array subgroup for at least three years,
but no formal proposal was made ahead of last year's deadline for new
material. This proposal includes a RANGE attribute for arrays and a
SET RANGE statement that sets the subscript ranges within the declared
ranges. There are also additional intrinsic enquiry functions for the
ranged bounds, size and shape.
ll. Pointers
Pointers were not discussed at this meeting except for a straw
vote on whether they should be on the list of items for the next
meeting, which was undecided (11-8-6). I asked for this vote since I
prepared a proposal for the September meeting, which has not been
discussed.
l2. Conformance
My proposal on conformance [3] was discussed, and it was clear
that it was not ready for a formal vote. I was clearly wrong in
suggesting removing the use of "must" and "must not" to indicate
requirements and prohibitions, since the document is being written
this way. My proposal also suggested placing a list of errors in an
appendix and requiring some indication of how the processor treats
each. I became convinced that the list would have to go in the
standard itself and I am worried about the time it will take to
produce the list and gain acceptance for it. The chairman would
prefer this material in some companion standard.
To: BCS, NAG, etc.
From: John Reid
Date: 27 January 1986
Subject: Report on X3J3 meeting at Sunnyvale, 20-24 January 1986
Note: This is a personal report on the meeting and in no sense
does it constitute an official record of it.
l. Summary
A significant vote was taken at this meeting. On a roll-call
vote, l7-11, it was decided that the time has arrived for a letter
ballot of the committee as to whether the draft standard is ready for
release for public comment. The response to this ballot has to be "no
with reasons", "yes", or "yes with comments". The chairman has asked
those voting "no" or "yes with comments" to bring technical proposals,
with text for the draft standard, to the next meeting. The committee
will seek to reach a consensus with noes replaced by yeses and
comments resolved. If consensus proves impossible, it is allowed to
proceed with a 2/3 majority in favour.
The probable reason for most of the 11 votes against a letter
ballot now is that the draft standard (S8) is not yet a polished
document, although it is improving fast (see section 3, below). I
voted "yes" because I want to process "in parallel" both technical
objections and editorial changes to the document, in the hope of
public release in the summer of this year. The IBM representative,
Dick Weaver, and a significant number of other members think that F8x
is too large (see section 7). The letter ballot will require each
member to state his or her position clearly and work on proposals to
correct the objections.
Most of the meeting was spent on detailed editorial improvements
to the document. We also made a significant change to the
interpretation of "deprecated" (see section 6), considered pass-on
precision, and extended the list of objects permitted as dummy
arguments to include allocatable arrays.
2. Passed-on precision
Good progress was made with the "combinatorial explosion"
problem associated with passed-on precision and exponent-range
parameters, though it was not fully resolved. The problem occurs
because (as things are now) on a machine with 3 precisions there would
be 3n versions of a procedure with n arguments having passed-on
precision. For example, there would be 35 versions of
SUBROUTINE MANY(A,B,C,D,E)
REAL(*,*)A,B,C,D,E
The favoured solution is to allow a dummy argument to be declared with
the precision of itself so that the above becomes
REAL (EFFECTIVE_PRECISION(A))A,B,C,D,E
if all five arguments are intended to have the same precision and five
separate declarations are needed if five independent precisions are
really wanted. It turns out to be important that intrinsics are not
available for the declared precisions, so comparable rules are needed
for derived types (e.g. for a type holding matrices).
3. Editorial changes to the draft standard
Very early in the meeting, it was decided to require a formal
vote for any change to the draft standard. This resulted in a very
large number of editorial papers, most of which were block proposals
containing many changes. The advantage is that there is a record of
every change that the committee made and any disagreements (e.g.
between the editor and a subgroup) were exposed.
These changes have greatly improved the document, but it is not
yet ready for public release. A particular problem is that the
section on scoping has not been adequately revised in the light of
nested internal procedures, type definitions, and interface blocks.
4. Bit data for masking
It was agreed by unanimous or near-unanimous votes to allow bit
data as an alternative to logical data for masking in the intrinsic
functions, WHERE, FORALL, IF, and CASE.
5. Allocatable dummy arguments
Functions whose results are allocatable arrays are already
permitted and it was agreed (19-7) to extend this to procedure
arguments. It was decided that it was inappropriate to permit intent
(IN, OUT, or INOUT) specification for such arguments. This is because
it is not obvious whether the intent should apply just to the
allocation status or to this and the actual value; in either case
an intent IN argument would be better as an assumed-shape array.
6. Deprecated features
Dick Weaver proposed strengthening the interpretation of
"deprecated" to say that the deprecated features "are intended to be
removed from the next version of the Fortran standard". He wishes to
provide firmer direction to users of the language making business
decisions about investing in revision of existing software. I was
opposed because of the cost of making such changes during just one
revision cycle. I was comfortable with the previous wording which I
interpreted as giving a strong push against use of the deprecated
features, while not actually leading to removal until their use drops
to a low level. The proposal passed (22-5).
7. Size of the language
Dick Weaver suggested (without text changes to the draft
standard) that modules, internal procedures, recursive procedures,
derived data types, and exception handling all be removed. He
believes that the language is larger than PLI or Ada and will not meet
the need of the community for a small, easy to learn, language with
simple and efficient computational model. He supported his case by
counts of numbers of statements, BNF rules, keywords, and intrinsic
procedures. It was not generally agreed that this provides an adequate metric
for comparing the sizes of languages. Jerry Wagener pointed out that it
indicates that Ada and Fortran 77 are very similar in size. On the basis of
the count of BNF rules, the Weaver proposal would reduce F8x by about 20% and
approximately halve the increment from F77.
TALK "USING DEC COMPUTERS IN THE FIELD OF DYNAMIC SIMULATION" -
DAVID HARRIS (ALPHA COMP LTD)
l.l. David Harris works for Alpha Comp Ltd located at Wareham, Dorset
who are a DEC OEM. He is also Chairman of DECUS (UK). In earlier days
he worked at the Atomic Energy Authority and his earliest computer
experiences were with the Ferranti Mercury. He did a lot of work there
on fluid flows and then set up his own firm Alpha Comp Ltd to do work
on simulators.
1.2. Why simulate?
l. To improve understanding of the process one was
trying to model;
2. It was cheaper to do a computer simulation than
actually build something in real life.
1.3. Examples of simulators:-
Flight simulators - reduced pilot training costs;
Chemical plant control system - optimise yields and
ensure safe operation.
1.4. Design considerations for a simulation package:-
Easy to use, eg menu facility;
Interactive displays;
Portable to real time;
Output in many forms;
Easy interface to other modules.
1.5. Most simulation packages are Fortran based, but very
few are portable to real-time.
1.6. Advantages of VAX for simulation:-
Virtual memory - reduces programming problems;
Accuracy of 32 bit word;
Extent of software available;
Cheapness compared with mainframes.
Disadvantages of VAX:-
Not so good value for money as PDP/11 for simulations;
Not suitable for real-time interfaces.
l.7. Advantages of PDP/11 for simulations:-
Cheaper than VAX;
Cost effective to dedicate a single machine to a study;
Can interface to real world.
Disadvantages of PDP/11:-
Slower than VAX;
l6 bit word offers reduced numeric accuracy;
Lack of available software, eg NAG.
1.8. For dynamic simulation the only languages worth considering are Fortran
and Pascal even though MOD are putting up a rearguard action on Ada.
l.9. DEC operating systems:-
RT ~ single user with multiple jobs spawned by one user;
RSTS - Resource shared executive aimed at the commercial
environment where each user shares time/resources.
l.l0. Unix and RSX:-
Bell Labs were using PDP/11 and wanted to do things in a real-time
environment; so they wrote their own operating system (Unix) to meet
the needs in this area which the native one could not provide. Later
DEC developed RSX (Real-time shared executive) which was much more
user friendly and secure than Unix. It is a multi-user operating
system in which each user can multi-task with different priorities. It
provides very high transfer rates to the real world and an environment
offering lots of facilities to the Fortran programmer. It is also well
documented.
l.ll. Which simulation package should one choose?
Visicalc - offers very cheap runs on small machines
but can only handle small problems. It
is easy for the non-expert to get the
wrong results.
ACSL - the other end of the spectrum from Visicalc
and very expensive.
Alphasim - an Alpha-Comp product which runs on lots
of DEC machines. It is interactive, written
in Fortran, can provide graphical outputs
and allows incorporation of other modules,
eg, NAG library.
l.l2. The future:-
Array processors offer good possibilities. In David's opinion PDP + array
processor would be more cost effective in this area than a VAX. He also
thought that Gould hardware offers the best value for money for simulation
although they have not got a good operating system.
l.l3. DEC products:-
David considers them of good quality and very reliable.