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).


4.      X3J3 Progress


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.


5.      Fortran Forum 85


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

appendix D.


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



APPENDIX A


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



APPENDIX B

CCTA letter  head

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




BSI letter head


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




APPENDIX C

To:           BCS, NAG, etc.

From:         John Reid

Date:         18 September 1985

Subject:      Report on XBJ3 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.



APPENDIX D


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.



APPENDIX E


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?