J A Bettess        - UCS

        J L Dyke           - HRC

        K Normington       - Coventry Polytechnic

        M Nunn             - CCTA

        T L Van Raalte     - MOD

        J D Wilson         - Leicester University

1.      Apologies for Absence

Apologies were received from B Meek, D Muxworthy, J Reid and D Vallance.

2.      Minutes of Previous Meeting [27 February 1984]

Correction. The middle of paragraph 2(i) should read:

        "The Chairman has asked for support for regular attendance at

        ISO FORTRAN Experts meetings. The amount involved would be about

        £1000 pa. An encouraging reply had been given."

3.      Matters Arising

        (i)     Due to the small attendance, probably caused by BCS HQ being

                so slow in sending out the newsletter announcing the meeting

                to members, it was agreed to put back the AGM to the June


        (ii)    No response had been received from J Roberts-Jones to letters

                from the Treasurer attempting to settle the expenditure for

                FORTRAN Forum. Our Group had previously asked BCS Secretariat

                to take responsibility for this long standing problem but still

                awaits a reply.

        (iii)   The Treasurer reported that BCS have allocated £600 to cover

                the Group's expenditure for 1984/5. Expenses include the

                newsletter, room bookings and speakers' expenses for meetings.

                (We had requested a budget of £607.)

        (iv)    Brian Meek presented the draft BSI Standard "Method of

                Specifying Requirements for FORTRAN Language Processors" to

                the ISO working group at CERN in April. It will appear as a

                draft document for public comment later this year. Membership

                of the subcommittee working on it comprises:

                        D Muxworthy (Convenor)

                        B Meek

                        I D Hill

                        J Wilson with P A Clarke and A M Addyman as correspondent


4.      Chairman's Business

        (i)     Our Group's costs, particularly sending out the newsletter,

                have been increasing so it will be necessary to put up the

                charge to non-BCS members in 1984/5. A proposal to set this

                at £5 will be voted on at the AGM in June.

        (ii)    Dates for meetings in 1984/5 were agreed as follows:

                        18 June 1984

                        19 September 1984

                        10 December 1984

                        11 March 1985

                Talks for the afternoons at these meetings (except June 18)

                have yet to be finalised. Anyone with suggestions should

                contact either the Chairman or Secretary.

5.      X3J3 Progress

        (i)     The Chairman produced a paper on FORTRAN 8X for the Geneva

                ISO meeting putting forward comments on the proposed new Standard

                raised in the UK FORTRAN Community. This appears in appendix A.

        (ii)    David Muxworthy produced a summary report on document S7

                (current proposal document for content of FORTRAN 8X) for the

                Geneva meeting. This is included in appendix B.

6.        ISO FORTRAN Working Group at CERN, Geneva

Although there will be a full report on the recent ISO FORTRAN Working Group

in Geneva at our June meeting, John Wilson gave a brief description of the

activities for those present.

The Geneva meeting took place between April 9-l2 and included both the

ISO Working Group proceedings and a Forum (chaired by Mike Metcalf of CERN).

The Forum

This consisted of:-

        - A short introductory talk by Jeanne Adams, X3J3 Chairman, on its

          activities and relationships.

        - An overview of 8X by Neldon Marshall (EG&G) with special emphasis on

          deprecated features.

        - A talk on Data Abstraction by Jerry Wagener (Chairman, ForTec

          Executive Committee).

        - A presentation of the Array Handling features by George Paul

          (IBM X3J3-member).

The talks were followed by a panel discussion session answering questions

from the audience, who seemed reasonably happy with 8X.

Main Meeting

        (i)     Timescales for 8X are expected to be:

                - draft Standard content agreed by end of 1984

                - draft circulated for comment early 1985

                - 2 year review period during l985-l987.

        The draft 8X document will go out to national Standards bodies

        including BSI in the UK. During the review period individuals

        wishing to comment on it can write direct to X3J3.

        (ii)    Fortran Information Bulletin

                This summarises the current content of 8X but has not yet been

                officially released by the X3 parent committee. [Some US

                computer companies have been against it because it might be

                misconstrued as being definitive.] The document, drafted by

                Jerry Wagener, is available to the BCS FORTRAN Group.

        (iii)   The earlier separate "core" and "modules" intentions for 8X

                have now coalesced into just one box. The new Standard will

                appear with "flags" against "deprecated features". Anything

                not deprecated is guaranteed still to work in the next

                Standard beyond 8X.

        (iv)    The attendees voted on several aspects of the intended new

                FORTRAN source forms with the following results:

                        multistatements per line - voted against

                        statements allowed before column 7 - voted for

                        retention of significant blanks - voted for.

        (v)     There was general opposition to BIT data type.

        (vi)    FORTRAN 8X, unlike F77, will have no subset language.

        (vii)   There was a general feeling in the American FORTRAN community

                that ADA had not achieved any great impact.

        (viii)  A survey of IBM users was reported as revealing that 70% use

                COBOL, 25% use FORTRAN and 5% use other languages.

7.      Any other Business

At our 27 February meeting Steve Hague from NAG gave a talk on the Toolpack

project. A summary of this, which was available too late for the last

newsletter, is enclosed as appendix C.

8.      Date of Next Meeting

The next meeting of the Group will be the AGM (postponed from the April

meeting). It will include a report by John Wilson and David Muxworthy

on the Geneva ISO meeting.

Mike Nunn (Secretary)

8 May 1984

Appendix A

Leicester Coat of Arms




Telephone 0533 554455

30th April, 1984.

Director of the Laboratory

D L Fisher, M A

Mr. Mario Surdi,



Neighborhood Road,



Dear Mario,

Here is the collection of comments on Fortran 8X,as promised,

for your Minutes of the Geneva ISO meeting. I'm afraid they appear

somewhat more verbose than the summary I gave at the meeting - but

please feel free to edit them if you want.

Yours sincerely,

John Wilson

Copies:    D.T.Muxworthy,  PLU Edinburgh

                C. Page, Physics Dept. Leicester

                M. Nunn, CCTA.


Some Comments raised by UK Fortran Community

        The following comments are based on discussions with two

groups of people : a) members of the British Computer Society

Fortran Specialist Group; b) the Physics Dept. at Leicester

University. England. They do not express consensus views but are

nevertheless representative comments of significant Fortran

users. I have only included the major points in this very brief


a) BCS Fortran Group

  i)    One reason for the slow take up of Fortran 77 by users was

        the initial lack of reliable and efficient compilers. The

        first compilers were usually full of bugs and much less

        efficient than Fortran 66 compilers in handling F66 code.

        As a result users became disenchanted with Fortran 77 and

        took a lot of persuading to convert to it.

        An acceptable validation scheme for F77 processors did not

        become available until 1983, 5 years after the release of

        the language. It is hoped the lesson has now been learned

        and a validation scheme for Fortran 8X will become available

        within a year of the language release. This will give users

        a degree of confidence in the reliability of processors.

        Efficiency is another matter!

 ii)    The BCS Fortran Group would like to propose that a

        "test-bed" processor be commissioned for the purpose of

        evaluating new language features. This would take the form

        of a prototype processor to check proposed constructs used

        in real programming situations. Some of the inconsistencies

        and ambiguities of Fortran 77 became apparent only after

        processors began to be used by real users. It is

        significant that several new language features in Fortran 77

        are now marked as "deprecated features">in Fortran 8X!

        It is felt that such a test bed processor should be

        available before and during the public review period of the

        draft standard. Afterwards it would be straightforward to

        adapt it to form the basis of a validation/verification

        scheme mentioned above.

iii)    The group questioned the meaning of terms such as

        "compatible with Fortran 77" from the point of view of a

        user. Such features as the new source form, storage

        association, significant blanks, Modules suggest that we

        will have two languages in one, the same way that one may

        have a dual state operating system on a particular computer.

        The F8X standard should clearly address this problem and

        define the inter-relationship not just from the point of

        view of the processor but also the user. It is noted that

        the standard does not talk of "users" - perhaps it should!

 iv)    Some users expressed a requirement for a local time zone

        intrinsic as well as local date and time. It seems some

        people want to have identical real-time programs running

        simultaneously in various parts of the world. There is also

        support for a CPU time intrinsic.

b)      Leicester University Physics-Dept.

        The following is an edited account of some comments supplied

        by Dr. Clive Page.

        General Impression

        Although most of the suggested changes to Fortran 77 can

        be justified individually, the overall effect is to make the

        language much larger and more complex than before. This has

        two distinct disadvantages. The first drawback is that most

        of those who write Fortran programs are not full-time

        computer specialists. They are, for the most part, just

        scientists, engineers, or whatever, using computers as tools

        in their ordinary working life. Often the computer is just

        one of many such tools. In order to write programs in

        Fortran one needs to carry a fairly complete working

        knowledge of the language in one's head. This is quite

        difficult for the intermittent user unless the language is

        simple and compact. Compilers for more powerful languages

        such as PL/I and Algol-68 have been widely available for

        some time but the languages have manifestly failed to catch

        on to anything like the same extent as Fortran. This seems

        to have surprised many academic computer scientists: for

        example David Barron wrote that "Fortran has survived,

        against all the odds, like some hardy weed". One of the

        main factors in the survival of Fortran is, almost

        certainly, the ease of use and small memory load it imposes

        on casual users. It is worth noting that the change from

        Fortran 66 to Fortran 77 actually tended to reduce the

        memory load: Fortran 77 has fewer exceptions to general

        rules than before, e.g. on the generality of forms for

        expressions, and has fewer intrinsic function names to

        remember because of generic naming. This more than

        compensates for the few additional statements and

        syntactical forms introduced by Fortran 77.  The next

        standard for Fortran should increase the complexity of the

        language as little as possible.

        The second drawback is that, if the language is as different

        from its present form as the present proposals would imply,

        most manufacturers will have to re-write their compilers to

        a substantial extent, and in consequence implementations

        will not become available for some years after the standard

        is defined. There is then a danger, some signs of which are

        already apparent, that Fortran will split into a number of

        incompatible dialects through the adoption of ad hoc

        extensions to Fortran 77 in different brands of computer.

        In the mean time those Fortran users who decide that more

        advanced facilities are essential will have transferred

        their allegiance to Ada instead. It would be much more

        constructive to make more modest improvements to Fortran

        which might have a chance of becoming generally available in

        the next few years. A more radical re-structuring of the

        language could then go ahead without worrying so much about

        incompatibilities with the present (obsolete) facilities.

        which would be two generations back.

        In this connection, a personal choice of the proposed

        changes which we could most easily do without would be as


        (a) Recursive use of subprograms.

        (b) Variant fields in user-defined data types.

        (c) Keyword arguments in subprogram calls.

        (d) Event handlers.

        (e) The more advanced array-handling options, e.g.

        shift-round functions, the passing of non-contiguously

        stored array sections to subprograms.

        Some of these features cannot, most likely, be implemented

        without a considerable hidden overhead. Although some

        scientific programmers have an unjustified preoccupation

        with execution-time efficiency, there are many applications

        where speed is genuinely important and a quest for

        efficiency is worthwhile. Another reason for the continued

        popularity of Fortran in scientific applications is the

        relative efficiency of compiled code on most systems. It is

        likely that, for example, if all subprograms have to be

        callable with keyword arguments the interface will have to

        be much more complex and inefficient than it is at present.

        Once users find that the overheads involved in CALL

        statements or function references are considerable, some of

        them will start to write their programs as a single program

        unit instead of dividing them into a sensible number of

        modules. This will more than reverse any advantages

        notionally gained by the supposed increased readability of

        keyword arguments. In fact most subprogram calls with

        keywords would be forced.to spread on to several successive

        program lines, so that readability might not improve much.


        The current proposals fail to include some features which

        are generally desirable and could be included without too

        much trouble.

        For example:

                The INCLUDE statement is a widely available and popular

                extension used to pick up program lines from an

                alternative source file. while some of its uses are

                covered by the new MODULE statement there are others

                which are not, for example the inclusion of INTERFACE

                definitions in a series of program units,

                The Fortran carriage-control convention of lopping off

                the first character in each record is hopelessly out of

                date and gets foisted onto different operating system

                in many different ways. On PDP-11 and VAX computers

                most sensible users create files with the non-standard

                option CARRIAGECONTROL='LIST' just to avoid the

                problems in this area. It is high time this archaic

                nonsense was removed from Fortran and a proper set of

                facilities provided to introduce carriage control

                characters into output files.

                Fortran programs which control or read data from

                electronic instruments often have to manipulate

                individual sets of bits in integer words. Most Fortran

                systems either supply intrinsic functions for bitwise

                logical operations (AND, OR, XOR, and SHIFT for

                example) or, even better, allow infix operations using

                the existing logical operators. It is true that the

                results are dependent on the word-length, but exactly

                the same argument is true of all arithmetic operations

                (e.g. one cannot add 80000 to an integer with

                confidence unless it is known that integers are stored

                with more than 16 bits) but this does not seem to stop

                people using operators or functions for arithmetic.

                The demand for bitwise logical operations is clear;

                most manufacturers support it in some way or another,

                but a standard is sorely needed.

                The end-of-file and error-handling facilities in I/O

                statements are still rather unsatisfactory in Fortran

                77: it is not always clear what the effect is when both

                IOSTAT= and ERR= are used together. Furthermore the

                error exits all behave like unconditional GOTO

                statements and thus mess up even decently structured

                code. Now that GOTOs and labels can be avoided in most

                other contexts it is a pity that an error or

                end-of-file exit has to involve the use of wild jumps

                and labels.

                The provision of so many new intrinsic functions makes

                the omission of a standard call to a pseudo-random

                number generator more notable. It would also be handy

                to have an error function (or some equivalent such as

                area under upper tail of Gaussian) available: many

                systems already provide both of these.

30th April, 1984.

John D. Wilson

Computer Laboratory

appendix B

ISO/TC97/SC5/WG9 (Fortran) Meeting, Geneva, April 9-12 1984.

Summary Report for BSI OIS/5.


The meeting was hosted by ECMA and held at CERN. There were 36

participants (2 Austria, 1 Canada, 3 France, 6 Germany, 1 Japan,

3 Netherlands, 1 Sweden, 6 U.K., 11 U.S.A., 1 E.E.C., 1 SEAS}.

The U.K. delegation was : P.A. Clarke, J.J. du Croz, B.L. Meek,

D.T. Muxworthy, D.M. Vallance, J.D. Wilson. The object of the

meeting was to review the current set of proposals by the ANSI

Fortran committee, X3J3, for the revized Fortran standard. The

language is tentatively known as Fortran 8X, the current proposal

document in S7 (standing document 7) of X3J3. Jeanne Martin was

elected chairman of the meeting and David Muxworthy, vice-chairman;

Mario Surdi was secretary.

Administrative Matters.

A draft summary of the content of S7, the Fortran Information

Bulletin (F.I.B.), had been voted on by ANSI X3 for release for

general public information; this had been approved 40-2, the

negative votes being from DEC and IBM, who both agreed to publication

subject to the document being amended.  It was agreed that the

original draft F.I.B. be circulated for information within SC5.

Prior to the SC5 Advisory Group meeting in Geneva on April 11, attended

by Brian Meek for the U.K., WG9 passed a resolution addressed to the

Advisory Group seeking to alleviate the anticipated problems of liaison

between program language groups and other related groups, caused by

reorganization of TC97. It also passed a resolution of full support

for Jeanne Adams as chairman of SC5.

In summarizing the decisions made by X3J3 since the previous meeting,

in June 1982, the X3J3 secretary emphasized the significant role played

by European based members (3 U.K., 1 E.E.C.).

Technical Matters.

A persistent, but possibly minority, criticism of Fortran 8X is that the

language has become too big. Therefore a major objective at the WG9

meeting from the X3J3 viewpoint was to obtain general support for their

decisions and to identify areas for possible deletion. As usual, the

strongest opinions were expressed in favour of adding yet more to the

language, principally bit data type, pointers, and varying length

character strings. Other attempted additions, such as the DO-WHILE

construct, were not approved. The only features which came near to

being candidates for deletion were (surprisingly) free form source,

entity-oriented declarations and recursion. An attempt to remove the

enhanced CALL was soundly defeated. Event handling looks likely to fail

however because the proposals are insufficiently developed. There are

areas, particularly in compatibility with Fortran 77, in array

processing and in the language description where expansion and definition

of proposals are still needed and WG9 made useful input on these matters.

In general however WG9 showed approval of X3J3's decisions.

Another objective from X3J3's viewpoint was to identify any feature to

which there was such strong objection that adoption of the standard

might be delayed or hindered. Other than compatibility with Fortran 77,

details of which have not yet been fully worked out, there appeared to

be no such item.

A discussion on the proposed Fortran binding for GKS uncovered a major

error in the Fortran 77 subset binding, namely that it was assumed,

incorrectly, that assumed length character dummy arguments were defined

in the subset language. This was so obvious an error it had escaped

previous examinations of the text. WG9 passed a resolution urging WG2

to replace the simulated enumeration data types using DATA statements

by PARAMETER statements and to move the relevant sample code to an appendix.

It also passed a resolution regretting that undue emphasis had been put

on the subset in designing the binding. The implication was that, taken

together with the error in the subset binding, it might be better to

produce separate bindings for the two languages. At the same time

concern was expressed that the full language binding should not be


Brian Meek presented the draft British standard method of specifying

requirements for Fortran language processors. Apart from a few comments

by people who had not grasped the underlying concepts, there were

questions of clarification but relatively little discussion. Probably

few had had chance to absorb the 61 page document. The question of

standard conformance is again being raised independently by two members

at the next X3J3 meeting so that hopes for a less permissive standard

for Fortran 8X still exist.

Full minutes of the meeting, including detailed summaries of all

discussions, are being produced and are expected to be available in

early June 1984.

Future Meetings.

The next meeting of WG9 has been provisionally arranged for July l-5,

1985 at GMD, St. Augustin, Bonn. An invitation is expected for a meeting

in the summer of 1986 to be held at Dalhousie University, Halifax,

Nova Scotia.

David Muxworthy.

April 23, 1984.

     appendix C

Technical Memorandum: NAG/T20-TPS                              page 1

Numerical Algorithms Group (NAG)

   Toolpack Project Summary

   B Ford, S J Hague

  Numerical Algorithms Group. Ltd

   NAG Central Office

    Mayfield House

   256, Banbury Road

    Oxford OX2 7DE

    United Kingdom


This paper reviews the background and aims of the Toolpack project, and

discusses the main design principles adopted.


1.        Introduction

1.1          General Background

1.2          Toolpack Project Objectives

2.        Toolpack Design Principles

2.1          Cooperating Tool Fragments in a File System

2.2          Environmental Flexibility

2.3          The Integrated Form

3.        Conclusions

4.        References

Technical Memorandum: NAG/T20-TPS                              page 2

1.   Introduction

1.1. General Background

Toolpack is the name of a collaborative project which began in 1979 and

involves several American institutions and NAG. Its aim is to improve

the Fortran programming environment by providing a powerful,

transportable set of programming aids to assist the development and

maintenance of Fortran software. These programming aids (i.e.

components of the tool set) will in due course include facilities for

tasks such as:

parsing                        dynamic debugging

static semantic analysis       program formatting

dataflow analysis              program editors

program instrumentation        precision conversion

and other aspects of program development and maintenance.

NAG, a collaborative software project, has been using pre-Toolpack

versions of a number of such tools since the early 1970's. We have in

the NAG Central Office established a partially automated procedure for

software refinement and assembly as part of our NAG Library activity.

These procedures and our experiences in using software tools are

described in more detail elsewhere [1]. NAG became involved in Toolpack

because we felt the need for a "second generation" [2] of Fortran

software tools both for our needs and in the Fortran user community


Within Toolpack, the primary development site has been the University

of Colorado at Boulder under the direction of Professor L J Osterweil.

Dr. W R Cowell of Argonne National Laboratory is Toolpack project

coordinator. The other American organisations represented in the

Toolpack management council are Bell Communications Research at Murray

Hill. Jet Propulsion Laboratory at Pasadena, the University of Arizona

at Tucson and Purdue University. NAG has been involved in Toolpack

since its inception as a contributor and latterly as the implementation

and assembly site for the final production version of the first release

of Toolpack as a public domain product.

An advanced prototype of the tool system described in section 2 has

been developed at Boulder whilst the assembly of contributed tools has

continued at NAG in preparation for the first release. due in 1983.

1.2. Toolpack Project Objectives

The primary goal of the Toolpack project is to provide strong

comprehensive support for programmers who are producing, testing,

transporting or analyzing mathematical software written in Fortran. The

specific objectives adopted are as follows:

Technical Memorandum: NAG/T20-TPS                              page 3

        (a)     the dialect of Fortran to be supported should encompass standard

                Fortran 77 and be carefully chosen to span the needs of as broad

                and numerous a user community as possible.

        (b)     Toolpack support is intended to be most effective in software

                projects of 'moderate' scale. By 'moderate', we mean for example

                production of programs of up to 5000 lines by a team of three

                programmers, say, or the analysis and transportation of programs

                of up to twice that size.

        (c)     The facilities provided by Toolpack may be biased towards

                interactive use but they must also operate in batch mode.

        (d)     The Toolpack suite in its various forms of use (see next section)

                must be highly portable, making only weak assumptions about its

                host operating environment. It must however be amenable to local

                tailoring to make effective use of available processor or backing

                store resources.

Above all, the tool capabilities to be furnished by Toolpack must be

powerful, efficient and easy-to-use. Previous experience has taught us

that many potentially useful tools have suffered mis-use or rejection

because they failed to meet these criteria. Given the diverse nature of

the Fortran user community it was recognised that the relative

importance of the three criteria would vary according to context. For

example, in one context, ease of use might be of paramount concern,

whereas in another, efficiency could be the main pre-occupation. The

desire to provide useful facilities for all of these contexts has led

to a strong emphasis on flexibilty of design, which is reflected in the

architectural principles summarised in the following section.(For

further details, see reference [3]).

2.   Design Principles

2.1. Cooperating Tool Fragments within a File System

Within the Toolpack framework it is assumed that the tools

("programming aids") operate on subject programs and the derived and

associated forms of those programs, all contained within a £i1e system.

The high level tools, such as a dataflow analyser, are composed of

inter-dependent tool fragments that take input from and place output in

that file system. That file system contains two kinds of files: "plain"

files containing some form of data and directories that contain lists

of plain files or directories. The plain files may contain.for example,

Fortran source programs, documentation test data, options to be used by

certain tools, Toolpack command sequences etc. The file system is

organised as a tree structure, similar to that of Unix (TM), with the

directories as intermediate nodes and plain files as leaf nodes. A

uniform naming convention and the provision of file structures (program

unit groups) that contain information about the composition of programs

help to make the invocation of tools simpler and more efficient,

especially where a suite of subject programs, rather than a single

program, is involved.

Technical Memorandum: NAG/T20-TPS                              page 4

2.2.  Environmental Flexibility

By carefully delineating and defining the interaction between a tool

and its environment [R] Toolpack construction principles allow the high

level tools to be presented to the user in an integrated form,

free standing utilities. Also, freedom to work inside or outside the

Toolpack file system is provided: files exist in either the portable

£i1e store or the host file store though directory control is only

provided within the portable system. Thus it is possible to use

Toolpack tools in several different environmental regimes. The

capabilities and routine definitions that make up the tool interface

are known collectively as the Toolpack virtual machine. Tools written

according to Toolpack construction principles [5] are portable between

Toolpack virtual machines. A portable implementation of a Toolpack

virtual machine is provided with the Toolpack release software.

2.3  The Integrated Form

Of the several possible modes of use, the integrated tool set based on

the portable file system is the most innovative and noteworthy.  The

tool set and file system used in this integrated way are referred to as

Toolpack/IST (Integration System for Tools). Toolpack/IST provides a

programming support environment in which the user invokes tools by an

"intelligent" IST command interpreter. This interpreter compiles the

user's request and determines the necessary steps and initiates

a chain of actions, i.e. tool fragment invocations, to carry out that

request.  The tasks involved in this process first involve traversing

the tool fragment dependency graph which specifies how the various

Toolpack file types are derived from each other through the application

of the tool fragments. The command interpreter then interrogates the

current state of the file system to determine if the required files

already exist and are valid for use. If the necessary files do not

exist but are derivable according to the dependency graph, the

appropriate instructions are generated by the command interpreter, as

part of the overall sequence of commands to be obeyed arising from the

user's request.

It is thus apparent that Toolpack/IST can best be viewed as a set of

basic tool fragments that can be assembled into tools upon user demand.

This notion has been pioneered in the Unix operating system where the

construction of tailored tool capabilities from small tool fragments

was supported by the pipe construct. In Toolpack/IST the tool

capabilities that are to be synthesized are far more ambitious than

those typically created as Unix tools. Therefore, the tool fragments

upon which we build are larger and more powerful, and the

interconnection mechanism is more sophisticated than a Unix pipe.

3.   Conclusions

Though the approach adopted by Toolpack has implications beyond

Fortran.  Our attention is at present firmly focused on support for the

Fortran programming environment. Toolpack must therefore present

Fortran with an opportunity for making significant improvements in

Technical Memorandum: NAG/T20-TPS                              page 5

their programming practice ("there are such things as good Fortran

programs and bad ones") but without asking those users to pay an

unacceptable price, namely abandoning the existing huge investment in

Fortran. We consider that the approach adopted by Toolpack represents a

significant and radical development but which at the same time

recognises the diversity of the Fortran user community and the need for

continuity. The first release of Toolpack is eagerly awaited and,

despite its limitations. is likely to have an immediate impact.

The outcome of the present project will be a number of useful Fortran

software tools but Toolpack can also be viewed as an experiment in

building a portable programming support environment. In that sense, the

first public release is not the end of the exercise but the start of a

major new phase which offers many challenging opportunities.

4.   References

     [1]  Ford B. and Hague S.J.

          'Tools for Numerical Software Engineering'

          NAG Newsletter NL1/81, Oxford, 1981

     [2]  Hague S.J.

          'Software Tools'

          Numerical Software: Needs and Availability

          Ed: D.A.H. Jacobs, Academic Press. London, 1978

     [3]  Cowell, W.R. and Osterweil L.J.

          'The Toolpack/IST Programming Environment'

          Argonne National Laboratory Report ANL/MCS-TM-7. 1983

     [4]  Iles, R.M.J.

          'What is TIE?'

          NAG Central Office, Technical Memorandum,

          NAG/T12-WIT, Oxford, 1984

     [5]  Iles, R.M.J.

          'Tool Writers' Guide'

          NAG Central Office, Technical Memorandum,

          NAG/T11-TWG, Oxford, 1984