BRITISH COMPUTER SOCIETY - FORTRAN SPECIALIST GROUP

Minutes of Meeting held at BCS Headquarters on Monday 2nd February 1981

Present:   G. Harding (Chairman)         ECMWF

M. Appleford                  Ove Arup Partnership

R. Bentley                    N.E.R.C.

O. Branley                    London Boro' Redbridge

P. A. Clarke                  Rothamsted Experimental Station

P. Croft                      Unilever Computer Services

J. L. Dyke                    Huntingdon Research Centre

E. Gorczynski                 B.P. Research Centre

S. Hague                      N.A.G.

D. J. Holmes                  Rolls Royce Ltd., Bristol

P. Jamieson                   Scottish Widows

M. Lee                        R. Watson & Sons

D. Muxworthy                  Edinburgh University

K. Normington                 Coventry Polytechnic

M. Nunn                       C.C.T.A.

J. Roberts-Jones              Liverpool City Council

G. A. Ruscoe                  O.L.B.S.S. Ltd.

J. Stewart                    SPL International

D. M. Vallance                Salford University

T. G. van Raalte              M.O.D.

A. Wilson                     ICL

J. D. Wilson (Secretary)      Leicester University

l.      Apologies

        An apology for absence was received from Mr. P. D. Bond, Philips Industries.

2.      Minutes of Previous Meeting [20 October 1980]

        Item 7, line 2: replace National Algorithms Group by Numerical Algorithms

Group. The Minutes were then accepted.

3.      Matters Arising

        A few members reported that they had not received their copy of the Minutes

or the Agenda. The secretary agreed to check the mailing list with BCS

Headquarters and asked members to inform him of any problems they experience

with distribution.

4.      Report from January Meeting of X3J3 - Berkeley

        D. Muxworthy reported on the main areas discussed at the recent meeting.

  (i)   John Reid gave a presentation on Groups and Internal Procedures. The

        Proposal has the following aims:

- replacement for statement function, extended range of DO and ENTRY.

- permit a single block of code to be executed in several places without

  destroying "clean" structure.

- data-sharing and name-hiding facilities for procedures that are private

  to a collection of procedures.

- flexible mechanism for a user to provide code needed during execution

  of a library "black-box" subroutine.

- binding together in a package a set of procedures designed for a

  single task.

- keep as simple as possible.

An INHERIT statement is used define global or common variable names; all

those not defined are assumed local. Nesting of internal Procedures is

allowed (any number of levels). An Internal Procedure may be called from

outside the host subroutine if it is labelled by the word ENTRY.

e.g.        SUBROUTINE HOST(X)

                <Code of host using variable Y>

                ENTRY INTERNAL FUNCTION MEMBER(A)

                        INHERIT X,Y

                        <Code of member>

                END INTERNAL MEMBER

        END

The syntax is illustrative only.

(ii)  Conformity Module This was initially assigned to Subgroup l0 (Core plus

Modules) for detailed evaluation. The committee was unhappy about calling

it a module: it should simply be referred to as the Conformity proposal.

The following proposals were put to the committee by D. Muxworthy.

Proposal l: That at a mathematical domain error (divide by zero negative

 square root etc.) execution of the program should terminate

 unless the program has explicitly made allowance for an

 alternative continuation by means of some event-handling device.

                      Straw vote: 19 for - 8 against - 8 undecided

 (objections were (a) efficiency, (b) will be better handled

 by hardware soon)

Proposal 2a: That a standard - conforming processor must have the ability

 to indicate whether or not the statements of a program unit

 conform syntactically to the standard.

Straw vote: 25 for - l against - 9 undecided

Proposal 2b: That the option to select conformance shall be expressed in

 the same manner as the option to select old-style or new-style

 program source (new-style being free-form i.e. significant

 blanks).

This proposal was withdrawn.

D. Muxworthy was asked where the Conformity Proposal should go from here.

There are two alternatives: either a formal task group controlled by X3J3 s

could be set up; or some informal group could carry on the work. There

seems to be little advantage in setting up a task group and no indication

that such a group would carry more weight with X3J3. There is no evidence

of much positive support from the rest of Europe. It was suggested that

the BSI group DPS/l3/WG6 be re-convened to develop the proposal. It was

also agreed that the BCS should continue to be pressed for financial support

to send someone to X3J3 meetings.

(iii) A formal vote was taken on the proposal that procedure calls be extended

to include keyword references, default values and entity-oriented

declarations (i.e. PARAMETER, COMMON, DIMENSION be combined):

formal vote 24-3.

(iv)  A formal vote was also taken on the proposal to add a USING statement as

the means of identifying a module to be used: formal vote 19-7.

(v)  The ECMA proposal to allow a decimal comma rather than a decimal point in

I/O formatted data was given a straw vote:

6 for - 16 against - l3 undecided.

(vi) A comprehensive Macro facility should be added: formal vote l8-8.

(vii) The concept of variable length character strings has been agreed in

principle: the form has yet to be finalised.

  J. Wilson expressed concern at the statement that independent compilation

of units will not be possible with the next Fortran standard. However it appears

that separate compilation will be possible; independent compilation, strictly

speaking, is not possible with current Fortran as COMMON variables can be changed

in different units.

The next meeting of X3J3 will be at Austin, Texas in March, followed by

Toronto in May.

5.      Fortran Forum

D. Muxworthy said that 9 members of X3J3 have indicated they will attend

Fortran Forums to be arranged in London and Edinburgh in October 1981. The

provisional dates are: London, Monday 12th October, Edinburgh, Wednesday 14th

October. The Edinburgh forum will be organised by D. Muxworthy and D. Marwick. A

small committee is being set up to organise the London forum - anyone willing to

help is asked to get in touch with the secretary as soon as possible. It is

suggested that the first part of the forum should deal with users' experience

with FORTRAN 77; the second with presentations from ANSI on FORTRAN 8X with

plenty of time for discussion. Presentations from non-ANSI speakers will be

sought.

6.      BCS Business

No news has been received on the status of BCS 81: chairman to investigate.

7.      Any Other Business

 (i)  The following press release has been received from AFIPS.

1982 will mark the 25th anniversary of the delivery of the first FORTRAN

compiler from the group at IBM which was led by John Backus. To mark

this occasion the History of Computing Committee of AFIPS has chosen the

topic of FORTRAN as the subject of the 1982 Pioneer Day Activities at

the National Computer Conference to be held in New York in May 1982.

Dr. J.A.N. Lee of Virginia Tech has been chosen as the chairman of the

organizing committee. (Dr. Lee is currently on leave at the Santa Teresa

Laboratory of IBM.)

Included in the preparatory activities of the committee is the collection

of historical anecdotes and stories about the development and use of

FORTRAN during the early days (say up to 1967) and in particular the history

of FORTRAN in non-IBM environments. It is also hoped to develop an archive

of FORTRAN related materials which would be deposited with the Charles

Babbage Institute; to this end, the committee would appreciate knowing of

the whereabouts of appropriate materials. Please forward stories, anecdotes,

names of pertinent people, locations and descriptions of potential archival

materials etc. (please use your imagination) to:

J.A.N. Lee

IBM Corporation, M43/D22,

555 Bailey Avenue,

SAN JOSE CA 95150.

(ii) The preliminary results of a FORTRAN 8X questionnaire sent out to the

European high energy physics community by M. Metcalf, CERN have just been

received. The report is reproduced, by permission, as Appendix A of these

minutes.

8.      Next Meeting

        The next meeting, the AGM, will be held on Monday 6th April 1981 at

BCS Headquarters. In the afternoon Alan Wilson, ICL will lead a discussion

on array processing proposals for FORTRAN 8X.

                         ---------------------------

Afternoon Session

        Steve Hague's talk on "Tools for Numerical Software Engineering"

is reproduced as Appendix B of these minutes.

APPENDIX A

FORTRAN 8x QUESTIONNAIRE (Preliminary results)

An article summarizing the proposed revisions to FORTRAN 77 was pub-

lished in the November issue of the CERN Computer Newsletter, which is

circulated among high-energy physicists engaged in software activities

throughout Europe. A total of 52 replies to the accompanying questionnaire

has been received, and the results are summarized below.

1.      No. of replies : 52.

2.      Repondants were mainly European physicists, with a few replies from

        American physicists and from systems programmers.

            3.

                    a) 6 repondants expressed the view that FORTRAN should remain un-

                       changed

                    b) 3 repondants (only one of them a physicist) thought that in the

                       long-term ADA should be adopted for high-energy physics program-

                       ming.

                    c) Respondants were asked to express their general opinion on the

 proposals, and to state whether they should be proceeded with

 quickly or slowly. The pattern of replies is shown in Table I,

 from which it may be concluded that the proposals meet with gen-

 eral approval, and that there is considerable support for moving

 fairly quickly.

Table I

4.      Respondants were asked to list the three most useful/interesting

        items from the list of 20 described in the article, and also the

        three least interesting/useful. In fact, many of the negative votes

        seemed to imply disapproval rather than lack of interest, and the

        voting pattern is shown in Table II. (Some replies contained fewer

        or more than the six votes requested).

Table II

It is possible to rearrange this voting pattern in a way which places each

item on a scale of concern (i.e. total no. of votes) against the distribu-

tions of votes between interest and lack of interest (or disapproval). I

have performed a rearrangement in this manner, shown in Table III.

Table III

The following points are of particular interest:

         i)     the overwhelming support for array processing;

        ii)     the surprising number of negative votes for the proposed

                looping construct;

        iii)    the lack of significant interest in such hotly discussed

                items as precision specification, environmental enquiry and

                internal procedures;

        iv)     the marked resistance to the introduction of recursion;

         v)     the complete lack of interest in I/O is probably due

                to the fact that physicists' requirements are either

                simple, or handled by utilities written by specialists.

   Of course, the classification into Table III is to some extent a

personal one, and replies may also have been partly influenced by the pre-

sentation in the explanatory article, but the overall trend is, I think,

clear.

  5.    A request for comments on the proposals brought the following edit-

        ed replies (some of them were up to three pages long):

         i)     requests for environmental enquiry to extend to the clock,

                date, machine type, CP time left or used, etc.;

        ii)     comments that the question of internal procedures versus

                macros should be clarified;

        iii)    pleas for more advanced types of dynamic storage;

        iv)     requests for the ability to link data structures;

         v)     worries about the efficiency of precision specifications;

        vi)     requests for more array operators, e.g. TRACE, TRANSPOSE,

                ORDER etc.;

        vii)    worries about the implications of the possible loss of

                independent compilation;

        ix)     strong emphasis that FORTRAN must remain an efficient

                execution language.

  6.    A request for comments on items not mentioned in the article re-

        sulted in the following edited replies:

         i)     a request for a wider variety of loop constructs, e.g.

                DO..WHlLE..UNTlL;

        ii)     many requests for alphanumeric labels;

        iii)    comments that FORTRAN 8x is no longer 'FORTRAN';

        iv)     requests for exception handling;

         v)     pleas for meaningful diagnostics and better run

                time support.

   In summary, I believe the number of replies and the seriousness of the

answers mean that the testing of opinion was both a worthwhile exercise,

and presents a reasonably accurate picture of the attitudes of the high-

energy physics community.

M.Metcalf

CERN, 1211 GENEVA 23, Switzerland.

APPENDIX B

Tools for Numerical Software Engineering

S.J. Hague and B. Ford

1.      Introduction

        Software tools in the context of this paper are programs designed

to assist in the development, testing, implementation, maintenance and

distribution of computer software. (These tools are sometimes referred

to as programming or mechanical aids). This paper deals with the

subject of software tools that operate on FORTRAN software, though

equivalent tools exist in some cases for other high-level applications

languages. Few non-trivial programs, once completed, remain entirely

unaltered throughout their computing life. In the next section we consider

why it is necessary to analyse and modify numerical software and the

benefit of mechanising such processes. Then we summarise software tools

in use by numerical software groups; the experiences of the Numerical

Algorithms Group (NAG) in using some of them; and in the final section

describe the recently formed Toolpack project.

2.      Manipulation and Mechanisation

        Before discussing software tools in detail, we must provide answers

to two basic questions which might be posed by the 'lay user' or perhaps by

the numerical analyst who suspects that his more software-orientated

colleagues are attempting to create a major new branch of computer science

with no real need for it. These basic questions are:

        (i)     why is it necessary to manipulate

                numerical software?

        (ii)    does the mechanisation of that

                manipulation process bring

                significant advantages?

2.1     Why May Changes Be Required?

        Answering this question poses little difficulty particularly if one

has witnessed the development of NAG from a single machine range library

project to its present state in which there are implementations of the

NAG FORTRAN Library on 28 distinct machine ranges. Within each

implementation there may be sub-implementations for particular computing

systems, e.g. on the CDC 7600, there are source text differences between

the Small Core Memory and Large Core Memory implementations. Similar

problems are faced by other groups who are also interested in developing

and maintaining high-quality software on many machines. Whether for

reasons of uniformity, portability or refinement, it is frequently necessary

to alter a body of source text either on a small scale or throughout an

entire suite of programs. Below are summarised a number of reasons which

might precipitate such changes:

-       correcting a coding error either of an

        algorithmic or linguistic nature.

-       altering the structural property of

        the text e.g. imposing a certain order

        on non-executable statements in FORTRAN.

-       standardising the appearance of the

        text.

-       standardising nomenclature used e.g.

        giving the same name to variables

        having the same function in different

        program units.

-       conducting dynamic analysis of the text

        (e.g. by planting tracing calls).

-       ensuring adherence to declared

        language standards or subsets thereof.

-       changing the operational property of

        the text (s.g. changing the mode of

        arithmetic precision).

-       coping with the arithmetic, dialect

        and other differences between computing

        systems.

-       altering similar algorithmic

        processes and similar software

        constructs in large collections of

        programs.

2.2     What are the Benefits of Mechanisation?

        Several published papers have eloquently argued the case for the

mechanised approach to program manipulation. Standish et al [2]

discuss the merits of improving and refining programs by means of an

interactive program manipulation system. Perhaps more immediately relevant

to numerical software, a paper by Boyle et al [3] discussed the advantages

of automating multiple program realisations; that is, deriving by mechanical

means, several members (realization) of a family of related programs from a

proto-type or generalised program.

        The main arguments presented for mechanisation usually concern two

factors: economy and reliability. If numerous changes are to be repeatedly

made to a large body of software, then the use of a mechanical aid offers the

prospect of considerable savings in time and effort. Presumably some poor

programmer is relieved of performing what would be a tedious and slow manual

task and can be employed on some activity with a greater intellectual stimulus.

The fact that the changes are made mechanically means that we can at least

expect consistency. It may also be that the mechanical nature of the

alterations are amenable to at least an informal (if not formal) proof of

correctness for the transformed program. The study of correctness-preserving

transformations is an active field of research, on the basis of which, some

developed form of a TAMPR-like system may eventually lead to software tools

whose operations are demonstrably reliable.

        In the light of the experience of the NAG Central Office in using

automated aids, our overall view would be that the use of such aids can

indeed lead to greater economy and enhanced reliability. We would add two

notes of caution, however. The first is that programming projects in general

are prone to take longer than expected. In an organisation of limited

resources, practical aims and subject to the day-to-day pressures of both

academic and commercial life, the decision to undertake the design and

implementation of a new software tool should be taken with perhaps more

caution than in, say, a research establishment. A second point of concern is

that the use of a software tool may lead to over-reliance upon its effective-

ness and so to a temptation not to check the output software closely. After

a tool has been successfully operational for sometime, complacency can arise.

If the tool is applied to data (i.e. programs) which contravene some un-

documented assumption made by its developers, then what we must hope for is

that the output is unmistakeably wrong even at a casual glance. If such a

contravention caused a somewhat obscure malfunction to occur, however,

incorrect coding may be generated without it being noticed.

3.      Software Tools in use

        To indicate the kinds of software tools in use, particularly by

numerical software groups, we give below a list of categories into which

tools might fall:

dialect verifiers (e.g. PFORT)

static analysers

data flow analysers

control flow analysers

program verification tools

test data generators

formatters (e.g. POLISH)

variant extraction        |

precision changes         | portability aids

value substitution        |

structuring tools

language translators

probe insertors

syntax-driven transformers

plus general text editors, string processors ...

        As examples, we summarise the properties of widely-used tools from two

of the above categories:

-    PFORT ([4]), produced by Bell Laboratories is a language dialect

verifier. It checks a program for conformity to the PFORT

Portable FORTRAN) dialect of ANS-66 FORTRAN, and also generates

information about program entities in tabular form.

-    POLISH ([5]) is a FORTRAN-tidying program developed by the

University of Colorado at Boulder. Its actions are to

- recalculate statement labels into a specified order,

- recalculate FORMAT labels into a specified order,

- adjust spacing in lists, comments and expressions

- indent the body of DO-loops

- terminate each DO-loop with its own CONTINUE

- move FORMAT statements to the end of a program unit.

     Though individual tools such as PFORT and POLISH are useful, well-

documented and easy to implement, the overall state of software tools for

applications programming is not satisfactory. Apart from the problems of

learning of and obtaining these independently-developed tools, the following

difficulties may also arise:

- the software tool developed on one system might be

  difficult to mount on another,

- the tool from an outside source may not be properly

  maintained,

- such a tool is likely to have a different user-inter-

  face from that of others from different sources,

- its effect may not be easily adjustable,

- its actions may be incompatable with other tools,

- it may rely on undocumented assumptions about the

  input program,

- each tool of any sophistication must perform some

  analysis of the program being processed. Much of

  that analysis is common to many tools but each

  performs it separately.

4.        The use of Software Tools in NAG

4.1      The Background to NAG

        The main aim of the Numerical Algorithms Group (NAG) project is the

development and distribution of a numerical and statistical algorithms

library. There are three language versions of the NAG Library; Algol 60,

Algol 68 and FORTRAN. The most widely-implemented and used of these three

is the FORTRAN version, Mark 8 of which ([6]) contains over 460 user-

callable routines. These routines plus their auxiliaries and associated

test software comprise over 200,000 source text records, and new material

will be added at later Marks.

        Thus, the overall software management task faced by NAG is the provision

of a large and still expanding Library which is available in several

languages and on many machine ranges; there are over forty, distinct,

compiled and tested implementations of the NAG FORTRAN Library, for

example. Manpower for this considerable undertaking is provided by a

combination of full-time personnel and voluntary specialists at a number

of institutions in the United Kingdom and elsewhere. Most of the full-

time personnel work in the NAG Central Office which is responsible for the

overall coordination of the project's activities. The main technical task

of the Central Office is the verification and standardisation of

contributions to the NAG Library, culminating in the assembly of a further

Mark (edition) of the Library, which is then passed on for formal certification

under various computing systems. The increasing use of mechanical aids by

the Central Office in its library assembly and processing work is summarised

below. For a more extensive description of the technical functioning of the

NAG organisation as a whole, see [7].

        Interest in mechanisation began to grow within NAG soon after the project

started in 1970. The Library was originally intended for a single machine

range (the ICL 1906A) but from 1972, other implementations were launched,

and the need for a multi-variant source text management scheme was perceived.

This led to the development of the NAG Master Library File System ([8]).

With the rapid growth of other machine-range versions, it became apparent

that, as well as having the means to store variants, it was even more

important to anticipate and minimise differences between implementations, i.e.

to remove those variations wherever possible. From its beginning, NAG had

intended to use a subset of the ANS-66 standard for its FORTRAN Library but it

became clear that adoption of a dialect intersection policy in name only was

not enough; conformity needed mechanical verification. The importance of

relegating and isolating machine dependencies was appreciated and the

desirability of mechanising other, unavoidable changes (such as precision

transformation) was also recognised, as were the benefits of a uniform

structure and layout of coding throughout the Library.

        Thus a major standardisation exercise, called Mark 4.5, was carried out

in 1974/5 to make the NAG Library software more portable and more uniform

in structure and layout. (At the same time, documentation was revised so

that it could support an arbitrary number of implementations.) From Mark 4.5

onwards, the Central Office started to use software tools such as POLISH and

PFORT mentioned earlier, and testing aids such as BRNANL ([9]). It also

developed a precision transformer, APT, and a standardisation tool, DECS,

which uses the output from PFORT to introduce explicit declarations for all

variables into a program (and can revise the order of non-executable statements

at the same time). The following diagram indicates the major processing

steps in the Central Office procedure for software processing. A few

explanatory comments may be required:

-       the verification stage is primarily linguistic;

        algorithmic validation has taken place at an earlier

        stage

-       several minor standardisation processes to introduce

        NAG conventions may be applied between DECS and

        POLISH

-       in the testing phase, the purpose of the test runs

        on machines X, Y, ... is to gauge the extent to

        which test results may differ. This is in anticipation

        of the formal Library implementation activity later on.

        To summarise experience within the NAG Central Office, our view is

that without partial mechanisation, the task of Library assembly and

processing would be extremely tedious, the code itself would be less

consistent, and implementation on different machine ranges much more

difficult - a point borne out in practice when pre- and post- Mark 4.5

implementations periods are compared. We are interested in improving our

existing tools to make them of use to our own collaborators but also see

the need for a more broadly-based and concerted effort to make these and

other useful tools more generally available. For this reason, we support

the aims of the Toolpack project.

5.      The Toolpack Approach (1980)

5.1     Background to Toolpack

        In the third section of this paper, we drew attention to some of the

unsatisfactory aspects of software tools in general. The recently-formed

Toolpack project has set out to remedy those defects and may start to have a

significant impact in 3 to 4 years time. It is a collaborative effort

whose aim, according to the Toolpack prospectus ([10]), is "to produce a

systematized collection of software tools to facilitate the development and

maintenance of FORTRAN programs." The potential Toolpack user could be any

FORTRAN programer but the proposed facilities are more likely to have

immediate appeal to the programming professional or the regular (but non-

computer specialist) FORTRAN user engaged in numerical computation.

        The reasons for starting a project with the aims and structure of

Toolpack can be summarised as follows:

-    numerical computation still represents a significant

proportion of all computer use, and FORTRAN is by far

the most widely used language for numeric applications

(and is extensively used in non-numeric areas too).

Toolpack is therefore addressing a potentially vast

audience,

-    software developers such as NAG have come to appreciate

the value of software tools both for their own work and

for the benefit of computer users generally. There is

also some experience of collaborative activities

amongst mathematical software groups,

-    research into software engineering has matured to the

point where an integrated ensemble of tools seems

feasible, and the integration attempt would in itself

be a worthwhile research effort.

5.2     Toolpack Development Plan

        The current intention of the Toolpack group is to carry out a three year

development plan which, if successful, could lead to the general availability

of facilities sometime in 1984. The plan contains three phases, the first of

which is already underway (see section 5.3.):

Phase 1:   Determination of the functional capabilities

to be provided by Toolpack and of the initial

packaging and integration environment.

Phase 2:   Implementation and documentation of tool

components within that environment.

Phase 3:   Packaging of the implemented tool components,

testing and refinement.

        The definition of packaging environment includes consideration of:

-       collection of basic tools (such as parsers, lexers,

        associated table managers).

-       input/output primitives,

-       specification of the subject language (i.e. the

   language of the programs upon which Toolpack will

   operate).

-       specification of the implementation language (i.e. the

   language in which Toolpack tools will be written),

-       user/Toolpack interface requirements,

-       inter-tool communication conventions.

        Investigation of these and other considerations is proceeding. It has

already been decided that the principal subject language will be FORTRAN 77

but it may be possible to allow other FORTRAN variants too - on input at

least - by concentrating the task of dialect recognition in the front-end

lexer/parser rather than in the processing tools themselves. The implementation

language has been defined to the extent that whatever language Toolpack

participants use initially, it must map into FORTRAN 77. The basic

principle of construction is uncontentious, the higher-level tools should be

built using lower-level modules where possible. Emphasis on "data-hiding",

i.e. not being specific about the exact details of data transfer and structure,

is also appropriate, particularly in the initial design stages. A point

under active discussion, however, is concerned with the user interface; should

an attempt be made to build an integrated information management system

which is directive-driven by the user, or should the less ambitious goal of

loose confederation of tools be pursued? Under the latter arrangement, the

user would drive each tool directly.

5.3     Candidates for Inclusion in Toolpack

        The following tools are under examination during Phase 1 and may be

included in the final set of facilities chosen for release. Other tools not

in this list may also be added. In most cases, the tools already exist in

a pre-Toolpack form and if chosen for inclusion will be reconstructed

according to the construction principle adopted. It should not necessarily

be assumed that such existing tools are currently available or suitable for

general release. Interested readers are advised to contact the individual

developers concerned, via the Toolpack coordinator (see next section).

      Tools under review include:

1.    DAVE: a static data flow analyser.

(The University of Colorado)

2.    POLISH: a formatter.

(The University of Colorado)

3.    BRNANL: a dynamic test probe inserter.

(The University of Colorado)

4.    BIGMAC: a FORTRAN language macro definer/expander.

(The University of Colorado)

5.    FSCAN/CLEMSW: a tokenizer/parser generator.

(The University of Colorado)

6.    A static semantic analyser/error detector.

(The University of Colorado)

7.    A floating point data generator.

(The University of California at Santa Barbara)

8.    FLOCHK: a structure and programming convention

checker.

(The University of California at Santa Barbara)

9.    IPUCHK: an inter-program-unit checker based on the

PFORT verifier.

(The University of California at Santa Barbara)

10.   STRUCT: a control flow structor.

(Bell Laboratories and The University of California

at Santa Barbara)

11.   The PFORT Verifier: a portability convention -

 checker.

(Bell Laboratories)

12.   The EFL Compiler: a translator for an extended

 FORTRAN language.

(Bell Laboratories)

13.   FORTLEX: a FORTRAN lexer.

(Bell Laboratories)

14.   APT-X: a precision type converter.

(The Numerical Algorithms Group)

15.   A FORTRAN-Intelligent Editor.

(The Numerical Algorithms Group)

16.   Template Processors.

(Purdue University)

17.   TAMPR: a program transformer.

(Argonne National Laboratory)

18.   A set of basic tools: lexers, parsers, symbol

table manipulators etc.

(Jet Propulsion Laboratory, Pasadena)

5.4     General Information about Toolpack

        The participating institutions in the Toolpack project at the present

time are:

   Argonne National Laboratory

   Bell Laboratories

   Jet Propulsion Laboratory

   International Mathematical and Statistical Libraries Inc.

   Numerical Algorithms Group Limited

   Purdue University

   University of California at Santa Barbara

   University of Colorado at Boulder

        The project has funding support from the National Science Foundation

and the U.S. Department of Energy.

        For further information about Toolpack, readers should contact the

Toolpack project coordinator:

   Dr. Wayne R. Cowell

   Applied Mathematics Division (Bldg.221)

   Argonne National Laboratory

   9700 South Cass Avenue

   Argonne

   Illinois 60439

   U.S.A.

   (Telephone: (312) 972 7164).

6.      Conclusions

        We have described how NAG's own experience in using software tools has

led to our involvement in the formation of Toolpack. Our belief is that if

Toolpack succeeds in its aims, the programming environment provided for the

FORTRAN user will be considerably enhanced. That environment for most users

at present consists largely of a FORTRAN compilation system and a general

purpose system text editor. Toolpack offers the prospect of a number of

additional supporting facilities which will make FORTRAN software easier to

develop and maintain.

7.      References

[1]     HAGUE, S.J.

"software Tools", In Numerical Software -

Needs and Availability,

Ed. D.A.H. Jacobs, Academic Press, pp 57-79, 1979

[2]     STANDISH T.A., KIBLER,D.F. and NEIGHBOUR J.M.

"Improving and refining programs by program

manipulation,

Proceedings of ACM annual conference,

Houston, Texas, pp 509-516, 1976

[3]     BOYLE J.M. and MATZ M.,

Automating multiple program realisation,

Proceedings of Computer Software Engineering Symposium,

New York., 1976

[4]     RYDER, B.G.

The PFORT Verifier, Software Practice and

Experience,

No.4, pp 359-377, 1974

[5]     DORRENBACHER J., PADDOCK D., WISNESKI D. and

FOSDICK L.D.

POLISH - A FORTRAN Program to Edit FORTRAN Programs,

Department of Computer Science Report #CU-CS-050-74,

University of Colorado at Boulder, 1974.

[6]     The NAG FORTRAN Library Manual, Mark 8

Published (1980) by Numerical Algorithms Group Ltd.,

7 Banbury Road, Oxford, U.K.

[7]     FORD B., BENTLEY J., DU CROZ J.J. and HAGUE S.J.,

Preparing the NAG Library,

This Volume.

[8]     RICHARDSON M.G. and HAGUE S.J.

The Design and Implementation of the NAG Master

Library File System,

Software - Practice and Experience,

Vol.7 No.1, pp 127-137, 1977.

[8]     FOSDICK L.D.

BRNANL - A FORTRAN Program to Identify Basic

Blocks in FORTRAN Programs,

Department of Computer Science Report #CM-CS-040-74,

University of Colorado at Boulder, 1974.

[9]     COWELL W.R. and MILLER W.C.

The Toolpack Prospectus

Argonne National Laboratory, Applied Mathematics

Division,

Report TM-341, 1979.

-------------------------------------------------------------------

NAG Central Office

7 Banbury Road

Oxford OX2 6NN

(Tel: (0865) 511245)

October 1980