BCS - FORTRAN SPECIALIST GROUP
MINUTES OF MEETING HELD AT BCS HQ ON 16 APRIL 1984
Present:
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
meeting.
(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
members.
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.
(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
COMPUTER LABORATORY
THE UNIVERSITY
LEICESTER LE1 7RH
Telephone 0533 554455
30th April, 1984.
Director of the Laboratory
D L Fisher, M A
Mr. Mario Surdi,
IBM
41P/920,
Neighborhood Road,
KINGSTON, N.Y.
USA.
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.
Enc:
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
summary.
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
follows:
(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.
Omissions
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
ISO/TC97/SC5/WG9 (Fortran) Meeting, Geneva, April 9-12 1984.
Summary Report for BSI OIS/5.
Introduction
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
delayed.
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.
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
Abstract
This paper reviews the background and aims of the Toolpack project, and
discusses the main design principles adopted.
CONTENTS
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
generally.
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