BCS FORTRAN SPECIALIST GROUP
MINUTES OF MEETING HELD AT BIRKBECK COLLEGE, LONDON ON 16 SEPTEMBER 1985
Present: P N Anderton - QMC
J A Bettess - UCS
John Dyke - Huntingdon Research Centre
Mike Ellis - Oxford University
Bill Flexner - Retired
Graham Poster - RAE (Bedford)
John Gordon - Rutherford Appleton Laboratory
D T Griffiths - SSF
Stephen Hart - ICST - Astrophysics
Chris Lazou - ULCC
Jack Levy - UCL Computer Centre
Heather Liddell - QMC
D Littlewood - NCC
Clive Massey - SWURCC
Brian Meek - King's College London (KQC)
Keith Normington - Coventry Polytechnic
Mike Nunn - CCTA
T L van Raalte - MOD (PE)
John Reid - Harwell
Neil Smith - RAE Bedford
John Steel - QMC
J Stratford - QMC
John Young - MOD (PE)
Addresses:
Chairman John Wilson
Computer Laboratory
University of Leicester
LEICESTER
LE1 7RH
Telephone: 0533-554455
Vice-chairman Keith Normington
Computer Centre
Coventry (Lanchester) Polytechnic
COVENTRY
CV1 5PB
Secretary Mike Nunn
CCTA
Riverwalk House
157 Millbank
LONDON
SW1P 4RT
Treasurer John Dyke
Huntingdon Research Centre
HUNTINGDON
PE13 6ES
1. Apologies for Absence
Apologies were received from Carol Hewlett, David Muxworthy, Lawrie Schonfelder,
David Vallance, Alan Wilson and John Wilson. As the Chairman was abroad
attending a User Group meeting, the Vice-chairman, Keith Normington, took the
chair.
2. Minutes of Last Meeting [10 June 1985]
The previous minutes were accepted.
3. Matters Arising
(i) The Group's accounts for the year ending 30 April 1985 were enclosed
as an appendix to the minutes. They showed a final balance in hand
of £1284.
(ii) Draft BSI Standard document, "Method of Specifying Requirements
for Fortran Language Processors".
Brian Meek (BSI committee member) described the background and
reported the latest position as follows:-
OIS is the overseeing committee on IT Standards. The BCS
representative on the OIS/5 Sub-committe dealing with
programming languages, is also a member of the international
working group on Fortran designated ISO/TC/WG/Fortran. A
meeting of the latter took place in Bonn last July and was
attended by David Muxworthy, Brian Meek as representatives of
OIS/5 and also by BCS Fortran Group members, David Vallance
and Alan Wilson. Its main purpose was to provide input to
the following X3J3 meeting.
At a recent BSC Study seminar it was agreed that BCS would
offer more support (including funding) to those involved in
standardisation activities, including Fortran. It was
considered that BCS's attitude to standards is relevant and
that the Society should from now on play a more influential
role in this respect. A report has been produced on the way
ahead. [The main part is in appendix A]. It was decided
that BCS should:-
- put forward a view on aspects of new Standards
- encourage development of Standards
- encourage chairmen of Specialist Groups and BSI
representatives to offer advice
- publicise Standards
- offer help with BCS representatives needing funding to
attend Standards activities
- make Specialist Groups responsible for producing notes
of guidance for representatives on Standards committees.
There will be a BCS meeting on Standards on 22 November.
Any Fortran user wishing to attend should contact Brian Meek.
The "Language Processor Requirements" draft is now released
for public comment. Its document number is BC 85/63877 DC
and is available from:-
The Sales Administrator (Drafts)
BSI
Linford Wood
Milton Keynes
MK14 6LE
Cost is £4 to subscribing members and £8 to non-members.
Comments must be received by 31 October.
[The Fortran Group felt quite strongly that:-
(i) the document was much too expensive (given it
was a draft soliciting comments).
(ii) it was not known to the Fortran world in general
where the document could be obtained.
(iii) the time allowed for public comment was far too
short.
It was agreed that the Secretary should write to the BSI
committee expressing this view. (See appendix B for letter
and BSI response)].
Anyone with comments on the draft document should send them
to:-
David Muxworthy
Chairman of OIS/5 Sub-committee
CAST
University of Edinburgh
18 Buccleuch Place
EDINBURGH
EH8 9LN
A BSI Fortran panel, which has been dormant, will now have
to be reactivated to vet comments received. This panel will
also be responsible to put in an official UK response on the
Fortran "8X" draft likely to be released by X3J3 for public
comment in early 1986. (Although there will be this official
UK response, it in now way precludes individuals submitting
comments and they will be highly welcomed by X3J3).
John Reid gave a summing-up of "8X" progress at recent X3J3 meetings.
Apparently a lot of time has been spent in Sub-groups cleaning up the draft.
At the July meeting in Oxford there was a vote to decide whether it was felt
that the proposed language was too large. But overwhelmingly the vote decided
it was not.
[Bill Flexner thought it was unfortunate that if the language is too large it will
be difficult to learn and become alien to many present users as well as
potential new users. Chris Laxou, however believed Frotran had had limitations
in some areas for serious users and "8X" needed to be larger to cater for these.
He felt that we would have to look at the X3J3 draft, came to grips with it
and then express opinion on the size, if necessary, during the public comment
period. Keith Normington said that a large standard document was offputting;
also a syntax was needed that was more consistent so that it was easier to
learn].
John Reid was just back from the September 9-13 Los Alamos X3J3 meeting which
had been called at short notice as an "extra" one in the calendar to help get
"8X" tidied up. As a result there were only 20 attendees and as a quorum is
14 participants one could effectively vote "no" by not voting at all. After
Los Alamos, the Fortran chairman, Jeanne Adams, will ask all X3J3 committee
members whether they consider the "8X" draft is ready to go out for public
comment. Anyone responding "no" will have to say why and come to the next
X3J3 meeting to express their reasons for objecting and offering alternatives.
The old Fortran 77 source form is now deprecated and may be removed from "9X".
There was a lengthy discussion on ordering of modules which are not sufficiently
precise in the present proposal. There is a slight problem with intrinsics
because, as new ones have been introduced in "8X", these will probably be
incompatible with many offered as extensions by existing F77 processors.
It has been decided to put a footnote in the Standard warning of this.
John has provided a detailed report on the Los Alamos meeting - see appendix C.
Chris Lazou (ULCC), chief organiser of "Fortran Forum 85" which took place
at the Institute of Education, London in July reported that the BCS Conference
Section had not yet processed all the receipts but the likelihood was that
our Group probably made a profit of between £500 - £1000. It was certainly
successful in terms of numbers with about 130 - 140 attending. The visiting
X3J3 speakers were very pleased with the Forum, indicating that it was the
liveliest and most thought-provoking of the various "Fortran Forms" which
had been arranged at different locations in the USA and Europe over the
last year or so.
The BCS Fortran Specialist Group committee apologise to all attendees on the
quality of the accommodation, which was very substandard. It was assumed we
would be allocated a much better room at the Institute like at the previous
Forum. Nor was the buffet up to our expectations. But we did have a problem
in that we only had about 30 bookings a few weeks before the event with a
last minute rush which we could not anticipate.
The opinion of the September meeting was that we should organise another Forum
for the Summer of 1986. Hopefully the final "8X" draft will be available
early next year and a Forum would provide everyone ideal opportunity to hear,
comment on and influence its content. Therefore it is the intention of your
committee to organise such an event. This time we promise you a superior venue
and an excellent lunch. (As a wine enthusiast I shall personally choose this
item!) We will advertise this event in the new year. We hope to bring some
ANSI representatives across the Atlantic specially for it.
Finally, the Fortran Committee wish to thank Chris Lazou for his outstanding
efforts in making sure "FF85" was a success.
6. NCC Fortran Validation Scheme - Talk by David Littlewood (NCC)
At the afternoon session, David Littlewood (NCC) gave a talk describing how
the NCC/FSTS Fortran 77 compiler validation scheme operated. A summary appears in
7. Death of Fortran
Who wants to kill Fortran? Certainly Gregory Aharonian does. Please see the
letter he has sent me from Massachusetts in appendix E. Any further
contributions (for or against) in this area I will gladly include in future
newsletters.
8. Date of Next Meeting
The next meeting of the Group will take place on Monday 9 December starting
at 1O.45 am at BCS Headquarters, 13 Mansfield Street, London. At the
afternoon session starting at 2.00 pm, David Harris of Alpha-Comps Ltd (who
is also chairman of DECUS, UK and Ireland) will give a talk on the use of
DEC computers in the field of dynamic simulation.
MIKE NUNN
Secretary
EXTRACT FROM BCS REPRESENTATIVES TO STANDARDS BODIES MEETING ON 8 JULY 1985
Winter conference
Mr Norman reported that a workshop for standards makers, including NCUF,
ITUSA, CECUA, IDPM, would be held in the Autumn; BCS was to be asked to be
associated with it. This was seen as separate from a BCS conference.
Suggestions for the conference were:
- that the theme should be 'How the Society can help to make better standards
and to improve present standards';
- that it should be primarily for BCS members, with invited participation by
BSI and other 'friends';
- that it should be held in March;
- that some of the topics to be tackled should be:
- Delegates, nominees or representatives?Are there too many standards bodies?
- Should the Society lobby?
- The Society's relationship with other bodies
- Should the Society spend more, and if so, on what?
- The role of e chartered BCS
- The conflict between work done by different committees
- How to encourage more interest in conformance to standards
AGREED
- that the steering committee to plan it should comprise Mr J S Hillmore, Mr A E
Sale, Mr R G Fiddes, the Standards Co-ordinator and the Secretary;
- that the steering committee should do some preliminary planning and report
back;
- that the Standards Co-ordinator should draft policy guidelines for agreement
at the next meeting;
- that the first conference should be a Society event;
- that a wider event should be held to enhance the Society's reputation after
guidelines had been laid down;
- that each representative should prepare a one page note on the activities in
which he is engaged for the next meeting; that these would form the basis of
an article in the Newsletter to advertise the conference; that the Staff
Editor should be invited to the next meeting;
- that information about the workshop on human factors and ergonomics in stan-
dards work, to be held on 14-15 October, should be circulated to all represen-
tatives, inviting them to provide input.
Next meeting
The next meeting cf representatives will be held at BCS Headquarters at 11.00am
on Monday 16 December 1985 and will consist of short presentations from the
representatives, followed by discussion of policy, as drafted by the Standards
Co-ordinator. A sandwich lunch will be provided.
ARDN/PW
9 August 1985
Mr H Walker
Secretary OIS/5
BSI
22 October 1985
Dear Mr Walker
DRAFT BSI DOCUMENT "METHOD OF SPECIFYING REQUIREMENTS FOR FORTRAN LANGUAGE
PROCESSORS"
At the recent meeting of the British Computer Society's Fortran Specialist Group,
Brian Meek told our members that the draft document "Method of Specifying
Requirements for Fortran Language Processors" was now available for public comment.
Our members felt strongly that they were not given sufficient opportunity to access
and comment on this and I (as Secretary) have been asked to express the following
dissatisfactions:-
1. The fact that the draft is entering a period inviting public comment is
not at all well known to members of the Fortran World in general. Few of
these people may be BSI members.
2. The document should certainly not cost £8, especially since it was only
a draft soliciting comments. Some people thought it should be free.
3. The date by which comments must be received (31 October) was quite
insufficient.
4. There needed to be much more publicity for such a document if BSI
seriously wanted to receive comments. Also it should be easier for the
average person to find out where to get a copy of the draft.
Perhaps your committee will consider these points at your next meeting. Our Group
would be pleased to hear your response.
Yours sincerely
MIKE NUNN
Secretary,
BCS Fortran Specialist Group
Mr Mike Nunn
Secretary
BCS Fortran Specialist Group
Computer and Telecommunications Agency
Riverwalk House
157/161 Millbank
LONDON
SW1P 4RT
25 October 1985
Dear Mr Nunn
REQUEST FOR PUBLIC COMMENT ON BSI PUBLICATION 85/63877 DC 'DRAFT BRITISH
STANDARD METHOD FOR SPECIFYING REQUIREMENTS FOR FORTRAN LANGUAGE PROCESSORS'
Thank you for your letter dated 22 October 1985 on this subject.
The BSI Committee OIS/5, which is responsible for this draft standard, will
meet next on 11 December 1985 when a Working Party will be appointed to
review comments received; the review probably taking place early January 1986.
Any comments that the BCS Fortran Specialist Group can submit will be welcomed
and warmly appreciated, though they should arrive by 1 December 1985 to allow
me time to process them.
The availability of the Draft for public comment was announced in the September
edition of 'BSI News' and the nominal two-month period allowed for receiving
comments is common to all Draft-Standards announcements. There is also
automatic circulation of the Draft to many international Standards Bodies, as
well as to each member of OIS/5.
Copies of the draft are available from our Sales Department at £8 for non-members,
and £4 to subscribing members of BSI.
Since we are not a profit making organization, the price reflects the cost of
publication and postage of the draft text, and does not recover the costs of
development in the committee.
We have no funding for wider methods of publicity, and apart from BSI News, we
must rely on the committee members to inform the organizations that they
represent.
I am very surprised that your group were unaware of the work being done on
FORTRAN, since there are four representatives from BCS, and two from CCTA serving
on OIS/5. So I suggest that you make contact with Messrs. A P Smith, M J Pickett,
G Prett, Dr I D Hill of BCS or Messrs. L Robbins, J Toller of CCTA (also R Moosai
receiving papers) and ask to be kept informed. In addition, I believe that
Mr Meek, Chairman of OIS/5 is also a member of BCS.
A copy of 'BSI News' is automatically distributed to
Mr Ward of CCTA
Room 717
Riverwalk House
Millbank
In view of the interest shown by your group, perhaps you would like to contact
Mr Meek, volunteering your services on the Working Party required to review
the comments.
Yours sincerely
H WALKER
Secretary to OIS/5
HW/SL
To: BCS, NAG, etc.
From: John Reid
Date: 18 September 1985
Subject: Report on X3J3 meeting at Los Alamos, 9-13 September 1985
Note: This is a personal report of the meeting and in no sense
does it constitute an official record of it.
References: [1] 96(*)JKR-l Language keywords (renaming project)
[2] 97(*)JKR-l Language keywords
[3] Draft British Standard Method for specifying
requirements for FORTRAN language processors
l. Summary
The emphasis of this meeting was again on getting the draft
standard, S8, into better shape. It is being stored and typeset on
Walt Brainerd's system in Los Alamos. All changes made at the meeting
were immediately keyed in by members of the committee and the aim is
to distribute the next version very soon. Following the changes made
at the next meeting (November) the chairman hopes to take a postal
ballot of members asking them if the document is acceptable for
release for public comment. Those voting "no" will have to say why
and bring proposals to meet their objections to the January meeting.
The ban on fresh technical proposals held well at this meeting.
The only technical proposals debated were those deemed critical
towards writing up the language as it now is. Queues have formed, one
of technical proposals and another of proposals related to comments
from the public.
2. Renaming project
Peter Kirby and I [1] constructed tables of all keywords in
Fortran 8x and proposed a number of changes. The tables were very
well received and greater consistency over naming was sought. However
in general the committee sought to void long names and the use of the
underscore character, which resulted in several of our proposals
failing. The following changes were made
(l) Wherever a leading keyword, for example BLOCK DATA, might
reasonably be spelt as one word or two (in one case three) words, both
forms will be allowed.
(2) FREE renamed DEALLOCATE.
(3) REAL_CHAR renamed EXPONENT_LETTER.
(4) EXP changed to EXPONENT whenever it refers to an exponent or not
to the exponential function.
(5) Argument name BACKGROUND changed to FIELD.
(6) Argument name A changed to X when it can only be real or complex
and vice-versa when it can also be integer.
(7) Intrinsics ABSSPACE and RECSPACE changed to SPACING and
RRSPACING.
(8) The function names beginning ACTUAL changed to start EFFECTIVE.
The committee has asked me to revise the tables to correspond to these
changes [2].
3. Masked array intrinsics
It was decided (16-l) that masked array expressions such as
SUM(A/B,MASK=B.NE.0.)
should be interpreted as requiring the full evaluation of the masked
argument, that is the normal rules for argument passing to procedures
should be adhered to.
4. Draft BSI Standard
Dick Weaver felt that the draft BSI standard [3] for specifying
requirements for FORTRAN processors sought to tie processors down
excessively. Lawrie Schonfelder explained that its purpose was to
provide a framework within which a procurement may be specified. The
committee expressed no opinion on the draft. The deadline for public
comment is 31 October.
5. Fortran 77 compatibility
The committee considered strengthening its statement on
compatibility to saying that any program conforming to F77 should
conform to F8x with the same interpretation, but it was decided that
this is too strong. Such a program will conform to F8x and one can
regard an F8x processor as an F77 processor, but as with two F77
processors the exact interpretation may differ. A particular problem
discussed was the use of new intrinsic procedure names which might
clash with user names for external procedures. However it was decided
(18-2-5) that no action was needed apart from a note of explanation in
S8, since F77 processors are allowed to have additional intrinsics.
To be fully portable, a F77 program should declare external procedures
with the EXTERNAL statement. Where this has not been done and a name
clash results, it is a easy matter to add an EXTERNAL statement.
6. Passed-on attribute values
It was decided (10-1-5) that some new syntax is needed for
passed-on attribute values (e.g. precision). To avoid a combinatorial
explosion it is usual to have a very small number (usually one) of
arguments passing on their attributes. Currently all those with the
same attributes have to be declared in the same type statement, which
is awkward and does not permit. the attributes of a complex variable to
be tied to those of a real or vice-versa. My preference is for some
kind of 'as for' syntax.
7. Syntax ambiguity in function headers
To avoid a possible syntax ambiguity when spaces are removed
between words in the old source form, it was decided (13-3) to add a
CONTAINS statement in front of the set of internal procedures in any
program unit and to permit only one interface in each interface block.
8. Module ordering
Kurt Hirchert believes that it was the committee's intention
when the module/use proposal was passed that when a program unit uses
a module, that module must (logically) precede it. That is, one
creates a module and then uses it. However the committee decided (13-4)
that it was inappropriate to talk of an ordering because it is not
the intention to demand a physical order. Instead there will be a ban
on a module reference to itself, either directly or indirectly.
9. Replacing RESULT
There are no clear rules in S8 over the typing of the result of
a function containing a RESULT specifier. The RESULT identifier is
needed to resolve the ambiguity that arises in an array-valued
recursive function. The committee was unsure (l0-7-2) whether to
return the result in an expression (probably as part of the return
statement) or to allow typing of either the function result or the
function name. I believe that there is no real difficulty over using
RESULT and have promised a proposal on this option.
10. Proposals in i/o area
The i/o group asked the committee whether it should prepare
proposals at this time on keyed access (l-l0-5), a delete-record
facility (6-4-6) and indexed sequential access (l-7-7). In view of
these votes, they will prepare a proposal for delete-record to go into
the queue of technical proposals.
ll. Next meeting
The next meeting will be November 11-15. The pre-meeting
distribution deadline is October 7.
NCC/FSTS FORTRAN 77 COMPILER VALIDATION SCHEME
- Talk by David Littlewood (NCC)
1. History
In 1973 the US Navy set up a project to test Fortran compiler conformance with
the ANSI Standard X3.9-1966 ("Fortran 66"). At the same time the US National
Bureau of Standards was also working on a test suite but this did not catch on.
By 1976 it was decided to change the objective to take into account the draft
Standard for the revised language ANSI X3.9-1978 ("Fortran 77"). At first
there was a test suite available only for the subset level language but
between 1980-1981 this was extended to include tests to include the full F77
language. Later there was a reorganisation and the administration of the test
service was carried out be a government body called the Federal Software Testing
Service. US government procurement laws require that for any Fortran compiler
to be eligible for purchase by Federal Agencies it must either appear on the
FSTS certified compiler list or have been submitted for validation and appear
on the annual schedule of compilers waiting to be tested.
In 1983 the NCC compiler validation service was set up and by arrangement with
FSTS uses the same Fortran test suite to validate compilers. Validation
summary reports produced by NCC are in the same format as FSTS and the two
bodies maintain a common certified compiler list.
2. Constitution of Test Suite
The tests are not designed to test a compiler's speed of compilation, usability
or the quality of diagnostics etc. They only check that the processor compiles
language constructs as per their definition in the ANSI Standard. The suite
comprises 272 individual tests (but each may contain a number of sub-tests)
which check correct implementation of separate areas within the total F77
language definition. In all, they equate to 112,000 lines of source code.
3. Carrying Out A Validation
Any user can ask to have a compiler tested. When this happens, NCC confirm
which version is requested together with the hardware configuration and operating
system environment.
Before the formal validation takes place, NCC or FSTS send the compiler
implementor a tape containing the test suite with appropriate documentation
for running the tests together with a list of requirements for the manner in
which they must take place. Once the implementor has run some of the tests,
he is asked to send back sample outputs showing results, compiler options
adopted etc. The implementor is allowed as much time as he likes with the tests
correcting bugs prior to the formal site validation by NCC or FSTS. When this
takes place, a member of these bodies takes a master copy of the suite to the
site and runs the tests. Any errors found are discussed immediately. Afterwards
NCC/FSTS produce a validation summary report (VSR) defining any errors found
during the validation, and the configuration on which the particular compiler was
tested. This is first sent to the implementor for approval - who can then decide
whether he is willing for it to be published and made public. In the CSA the
Freedom of Information Act ensures such information is freely available. In the
UK, VSRs are available for free (for compilers tested by either NCC or FSTS).
Anyone wanting any of these should write to:-
Vony Gwillim
Senior Consultant
Standardisation Office
National Computing Centre Ltd
Oxford Road
MANCHESTER M1 7ED Tel: 061-228-6333
Running an initial validation may take NCC 2-3 days on site; but revalidation
can often be achieved in about 3 hours.
4. Certificate of Validation
After validation a certificate is issued even when a compiler contains errors.
The only time when one is refused is at a re-validation. Any compiler must be
re-validated 12 months after the previous validation. Moreover, any errors
reported on the previous validation must have been cured (although new ones
would be allowed!) otherwise a certificate is refused and that compiler is
included in a category designated as "compilers dropped from previous Certified
Compiler List" which is like a black hole from which one cannot re-emerge, and
a great embarrassment to the supplier. Compilers which are not submitted for
re-validation (unless exemption is allowed) will also be put in this category.
Exemption may be allowed if:-
(i) the implementor certifies that no modification has been made since
the last validation
and
(ii) two previous annual validations of that compiler were satisfactory.
5. Suite Maintenance and the Future
(i) Originally the test suite was run against a lot of compilers to get rid of
bugs. It is maintained by FSTS who will not upgrade it any further. NCC
will probably write a Fortran "8X" test suite when the new language is
published and, if necessary, will recruit people to do it.
(ii) Of the 57 Fortran compilers so far validated, 7 were tested by NCC. Cost
of validation (charged at £250 per man day) tends tc be about £2000.
(iii) From 1 October 1985, NCC will also be testing ADA compilers using
the same validation suite developed by DoD and administered by FSTS.
There are plans for validating GKS implementations as well.
LETS KILL FUTURE FORTRANS
Gregory Aharonian
Source Translation & Optimization
P.O. Box 404
Belmont, Mass 02178
617-489-3727
With the work on Fortran 77 complete!, the work on Fortran 88 underway, and the
work on Fortran 99 contemplated, it is worthwhile to stop and consider if this
progression is needed. While there are many technical arguments in favor of future
versions of Fortran, there have been few social arguments. What follows are some social
arguments against any further development of Fortran, stated more to start an argument
than to prove a point. These arguments also apply to crutches such as Toolpack.
Three main requirements drive the development of Fortran 88 and Fortran 99. The
first is to provide a Fortran that aids algorithm development on non-sequential
architectures. The second is to provide more powerful language features, such as
structured data types, concurrency, modularity, and other C and ADA like capabilities.
The third is to retain use of old Fortran programs, in particular the numerous
numerical analysis packages, such as Linpack and Eispack.
In a world where Fortran exists only through IBM and DEC compilers, it is obvious
that future more powerful Fortrans are needed. Fortunately, the world in this sense is
much bigger, and the need for future Fortrans less obvious. Let us consider each
requirement in the "real" world.
NON-SEQUENTIAL ARCHITECTURES
Parallelism is probably the main driving force for future Fortrans. Yet
developments in the non-sequential marketplace are eliminating the need for expressing
parallelism. Many manufacturers of non-sequential architectures are providing Fortran
77 compilers that have optimizing sections that can detect any parallelism. Thus for
Fortran programs written in a style that reflects that this optimization will happen,
there is no need for constructs in Fortran to express the implicit parallelism. If the
applied math community can ever agree on an extended BLAS to handle vector/matrix
operations, there is even less need for parallel constructs. Companies are developing
tools for rewriting Fortran programs to bring out the parallelism, such as Parafrase.
Finally, many non-sequential companies are developing C compilers for their machines,
since they use microprocessors and are hooked on UNIX. If this trend continues (which
it should), then the use of Fortran 88 and 99 will aggravate software maintenance
problems by forcing people to maintain code in many languages. Thus the realities of
the marketplace are such that the need for parallel constructs in Fortran are no longer
that important (use APL).
PROGRAMMING LANGUAGE CONSTRUCTS
Like economic and religious systems, programming languages in time will converge
to the same structure modulo keyword names. Even APL, Lisp, and Forth, three non-
standard languages, are starting to add features from general purpose languages. This
convergence is certainly true for Fortran, as it grows in size to incorporate
everything, with Fortran 99 destined to be as messy as ADA. Eventually writing Fortran
programs will be as tedious as writing ADA programs, having to declare and modularise
everything, without the benefit of receiving ample amounts of DOD money to keep you
happy. Instead of creating and introducing new versions of Fortran, it will be
admirable for the Fortran community to convert to one of the existing higher level
languages, in particular C, enmasse (a first in programming language history).
Switching has many advantages for the Fortran community. We can let others in the
computer community worry about language development (and many more C and ADA people are
doing this), and return to important tasks like using computers to solve real problems
(in return for killing Fortran, the C community should extend the +-/* operators to
COMPLEX numbers). A growing number of C tools, spawned by the UNIX community, can aid
science and engineering program development considerably, and help those using Fortran
for other purposes. For example, one of the best algebraic manipulation programs
is SMP, while one of the most powerful automated reasoning systems is LMA. Both are
written in C and have many uses in the science and engineering community (LMA can prove
hard theorems, an untapped area). Finally there is the growing problem of multi-
language software maintenance, with sites having to support the same algorithms in
Pascal, Fortran, C, Ada and Lisp. One way to simplify this problem is to eliminate a
few languages.
Another concern in language choice is the supply of programmers. The academic
community, which provides the majority of programmers for all applications, has been
deemphasizing Fortran. Fewer courses in Fortran are offered, as Pascal, C, Lisp, and
now ADA are used to teach the principles of programming, and in implementation courses
such as numerical analysis and database design. While you don't have to be taught
Fortran to use it, programmers will be more productive using the languages they are
taught. The latest techniques developed by computer scientists will become harder to
implement in Fortran (unless it becomes as big as ADA, at which point you might as well
use ADA).
It will be nice if scientists and engineers agree that Fortran has had it, and
switch to C, instead of adding and patching, until the white sock becomes a black shoe.
OLD FORTRAN PROGRAMS
A main concern for many installations is their large collection of Fortran code,
which they don't want to recreate from scratch for new environments and languages. An
argument in favor of Fortran 88 and 99 is that the old Fortran programs can gradually
be moved to the newer languages with minor modifications. This approach seems to duck
the issue by pushing the conversion problem into the future (a safe managerial
approach). With a growing number of software tools for converting Fortran programs,
this requirement also becomes less crucial in time. For example, at STO, we have
developed an intermediate language from which we can generate programs in many
languages automatically, having rewritten the program only once. This approach
gives multi-language compatibility, reduces software maintenance problems considerably,
and allows well developed Fortran algorithms to be used in many more environments.
CONCLUSION
By itself, there are many reasons for developing Fortran. However, when
considered in the much larger computing community, the problems become more social and
less technical. From this wider view, the need to develop Fortran becomes less
important, to the point of creating more problems than solutions. As the Defense Dept.
migrates to ADA, and requires all of its funded research to program in ADA, the
majority of which is now programmed in Fortran, there will be a very strong external
force on the Fortran community. Along with the migration of hardware manufacturers to
C, any resistance to change seems futile. I suggest that the Fortran community spend
some time to see if it will be more useful to technology efforts if Fortran is killed.
Having given up simultaneity, determinacy and locality in the physical world, can't we
give up Fortran in the computer world?