BRITISH COMPUTER SOCIETY - FORTRAN SPECIALIST GROUP.
MINUTES of the Annual General Meeting held on Monday 2nd April 1979
at British Computer Society, 13 Mansfield Street, London W1.
PRESENT:
E A Booth British National Oil Corporation
P A Clarke Rothamsted Experimental Station
G L Harding E C M W F
D J Holmes Rolls Royce Ltd., Bristol
P Kraven British National Oil Corporation
B Meek Queen Elizabeth College, London
J D Murchland Leeds University
D E Oldfield International Computers Ltd.
D K Phillips International Computers Ltd.
T L van Raalte Ministry of Defence (PE)
J M Roberts-Jones Liverpool City Council
D M Scales Seismoqraph Service (Eng) Ltd.
A W Stewart Geisco Ltd.
A Wilson International Computers Ltd.
J D Wilson Leicester University
APOLOGIES FOR ABSENCE:
D Hill, D T Muxworthy.
(Mr P A Clarke in the Chair)
APPROVAL OF MINUTES:
The minutes of the meeting held on 5th February 1979 were approved.
MATTERS ARISING:
Disposal of Surplus. MOTION (Meek) that all BCS Branches be
approached with an offer to provide speakers on Fortran standardisation,
this Group to defray speakers' expenses. Passed unanimously.
Disposal of Surplus. It was suggested that a bulk purchase he
made of copies of the new standard. it was noted with regret that
orders placed with BSI were subject to delay and that the price charged
appeared excessive. The Secretary reported that he had previously
attempted to negotiate with BSI, who had offered a discount so small
that the savings would he more than offset by the costs of postage to
members. Unfortunately, there was an agreement between BSI and ANSI
giving the former a monopoly of supply in the United Kingdom, and it
was reported that orders placed directly with ANSI were being refused.
It was felt that it was now too late to consider local reprinting.
RESOLVED that Mr D T Muxworthy, as Convener of the relevant BSI Working
Group, be asked to register the Group's concern as to the arrangements
for distribution of the new standard.
RESIGNATIONS:
Mr P A Clarke indicated that he was resigning as Chairman. It was
reported that Mr D Hill and Mr M Lewis were resigning from the
Committee.
ELECTION OF OFFICERS:
The following nominations were made:
Chairman: Mr G L Harding (proposed J D Wilson, van Raalte)
Vice-chairman: Mr D T Muxworthy (Meek, Harding)
Secretary: Mr J M Roberts-Jones (van Raalte, Meek)
Committee: Mr P A Clarke (Meek, van Raalte)
Dr J D Murchland (Clarke, Meek)
Dr A Wilson (Clarke, Meek)
Mr J D Wilson (van Raalte, Harding)
All nominations were accepted unanimously and the above-named
Officers were declared elected.
(Mr G L Harding in the Chair)
Meek made a statement in support of the X3J3 core-plus-modules
proposals. He noted that he was in a small minority amongst the U.K.
delegates to the ISO meeting in having no reservations about the
proposals. He supported the concept (but not necessarily the actual
implementation).
There were conflicting requirements needing to be resolved in
the design of any language. In the case of a language such as Fortran,
there were considerable historical influences such as the reduced
character set. Users had very strong desires for maintenance of strict
upwards compatibility; but they also wanted a variety of new facilities.
Such new features should address particular application areas, such as
a database interface (which was now required by X3 to be considered by
X3J3), and extensions for real-time and graphics. In addition, there
were more general requirements for the language to be developed to
exploit advances in machine architectures and to recognise trends in
the usage of programming languages: there were needs for array handling
capabilities, for freer source forms allowing for terminal input, and
for useful structured programming constructs beyond the block IF, such
as better looping, and case, statements. There was also a desire to
rid the language of a number of "archaic" features.
On the other hand, it must be recognised that continued addition
of features to the standard can cause compilers to grow, and grow.
As he understood the proposals, the intention of X3J3 was that
'Fortran, with all these extra goodies added to it, ... would be
stripped down to a core consisting of those data and control structures
that were strictly essential for "old-fashioned" programs; the core
would be a truly minimal subset.' A number of Fortran 77 features
would be omitted from the core, which would be A subset (as distinct
from the subset) containing those features it was desirable to retain.
The core language would be a viable language. It would not be downwards
Compatible. In any particular implementation, one or more nodules would
be available in addition to the core. It was an essential feature that
a user could specify; invocation of particular modules. Some modules
might be implemented as subroutine libraries (e.g. graphics), whilst
others might add new statements or new variants of existing statements
(e.g. database).
In order to provide upwards compatibility for existing programs,
a module would always be provided, containing those Fortran 77 features
deleted from the core. He felt that the terms "Fortran 77 module" and
"archaic features module" were misnomers: he would call it a
"compatibility module".
Harding suggested that for some micros there would be little point
in preserving Fortran 77 compatibility.
Murchland expressed doubts as to whether a full implementation
containing all modules was feasible.
(At this point, Mr B Meek left the meeting.)
Murchland said that he was opposed to the X3J3 proposals. He had
reservations as to the stated intention to get a modern language whilst
maintaining existing programs. X3J3 ought to recognise their inability
to cover the full range of Fortran usage. He regretted moves to
discriminate against "unloved" features.
Harding stressed that there was an urgent need for a new standard
interface; he welcomed the impetus given by the core-plus-modules-e
proposals to development of an enhanced procedural interface.
Clarke made a statement opposing the core-plus-modules proposals;
this is attached as an appendix.
Harding felt that the fact that the proposals envisioned
maintenance of Fortran by several different committees was no more than
a recognition of the existing position; future development would be
assisted by a formal interface definition.
There was a short discussion as to potential alternative
approaches. Harding suggested that Fortran was one of the very few
languages that did get updated; it was not realistic to compare the
necessary design process with that of languages which were immediately
frozen. Clarke wished to avoid the possibility that the proposed
approach would make it easier for "silly" features to be added to the
language. Harding said that the test was whether implementors and
users adopted new features. Kraven felt that, no matter what the
standards said, users will continue to write whatever they want to.
van Raalte pointed out that a module that proved to be popular could
nevertheless include individual features that might be undesirable.
Alan Wilson gave a very interesting talk. He first described
the current state of discussions within X3J3 on the provision of array
processing features. He then described the ICL Distributed Array
Processor and gave examples of the algorithms being developed to
exploit it.
NEXT MEETING:
Monday 4th June 1979, 10.30 a.m., British Computer Society,
13 Mansfield Street, W1. The main speaker, at 2 p.m., will be
Mr W D Manville of GEC Computers Ltd., on "Fortran Systems for
the GEC 4000 Series".
(CLARKE)
Some thoughts on the core-plus-modules
approach to standardising Fortran
The case for a core-plus-modules approach has been formally proposed by
Walt. Brainerd at the meeting of Fortran experts (Nov. 78) and at Fortran
Forum (London) (Dec. 78), a copy is attached to these minutes. (Appendix B)
These comments refer to technical and other problems associated with
core-plus-modules (that have been raised in subsequent discussions) in
an attempt to clarify the full range of implications of its adoption.
The comments on the proposals can also be classified by their impact on
(a) Existing Fortran programs (b) Existing implementations (compilers etc.)
(c) The Organisation necessary to support Fortran standards (d) The Fortran
User (e) The Fortran language and (f) General comments, observations and
opinions.
Impact on Existing Fortran Programs
Many people have claimed that the use of Fortran 82 would be for new
programs only. This is because the Fortran Core language proposed is
incompatible with F77. Existing programs would have to be developed and
maintained by use of the Fortran 77 module. Within a program it is not
possible to have some routines in F77 and some in F82.
For an existing program to operate under Fortran 82 requires that it be
completely rewritten (without COMMON, EQUIVALENCE, computed GO TO etc.).
If this is the case, and it seems so - then why not change completely to
another language - one that is more powerful than F82 and get even larger
benefits from the effort of rewriting?
The tremendous changes proposed for Fortran 82 defeat the purpose of
"evolutionary standards" (if such things exist).
Impact on Existing Implementations (Compilers etc.)
It would appear that the compilers of a core-plus-modules language would
have to be structured themselves into modules to handle the core and each of
the modules necessary. How the compiler handles incompatible modules is not
known.
Certainly because of the retention of old/redundant features, compilers
will also have to carry a large overhead.
There are no implementations of core-plus-modules Fortran and hence
no-one knowns how it will be implemented or even if it can be implemented
successfully.
A runtime system to support core-plus-modules with incompatible modules
is not a practical proposition. Only compatible modules could be used at the
same time. There would be no way that the runtime system could check to see
if the modules (routines) used were semantically compatible - this would be an
additional source of uncheckable "user error".
Impact on the Organisation of Fortran Standards
Difficulties arise in co-ordinating changes to any of the standards and
in particular, changes to the core language. As we understand it, ANSI X333
will be responsible only for the 'core' language and the Fortran 77 module.
Will they also be responsible for determining which of the proposed modules are
to be standardised? Or is a new organisational structure necessary, possibly
along the following lines? The way authority is to be delegated to these
various committees should be made clear.
X3
|
|
X3J3 - Fortran system Co-ordination
|
-------------------------------------------------------
| | | |
X3J3 - Core Fortran ISA standards CODASYL Database etc
| (real time) Standards Group.
|
-------------------------------------------------------------
| | |
X3J3 - Fortran (77) X3J3 - Subset Fortran X3J3 - array processing
module (module)
There is a problem that no single group are now masters of the whole
application spectrum and there will be no one to speak authoritatively for the
whole of the standardisation activity.
Impact on the Fortran User
There certainly is a requirement to be able to support 'language
extensions' for major application areas and users would benefit from having a
standard way of tackling these problems.
The proposals that exist lack detail. Many of the 'reorganisations' that
appear to be implied by core plus modules (such as "deletions" on a grand
scale) are unacceptable to many users, and haven't been 'thought through'
adequately.
The Fortran user may be able to write Fortran 77 programs that will
conform to F82 - but because of the extensive nature of the changes, these
programs would either be trivial or excessively badly written because of
exclusion of features due for deletion.
The User of a core-plus-modules compiling system must be aware of what
features he is using are in the core and what features are in modules, and
what modules are incompatible.
In fact, the problem may exist at a sub-module level. Only some of
the features in one module may conflict with some of the features in another
module (or the core module). For example, provided labels are not removed from
the language, the computed GOTO in the Fortran 77 module could be used in the
same program unit as CASE statements of the Fortran 82 core. But it is believed
that COMMON and EQUIVALENCE could not similarly co-exist with array processing
and fixed form source could not be mixed with free-form source.
Impact on the Fortran Language
The addition of various modules(super) - languages will in effect make
Fortran a larger language system. This means that any changes will have wider
ramifications and more time will be required to produce extensions that do not
conflict within the system - it will also become increasingly difficult to
devise such extensions. The overall effect will be to cause a slowing in the
rate at which the language develops. This is contrary to the rapidly developing
hardware environment currently prevailing, and I suspect, (from the list of
Brainerd's proposed changes), to Brainerd's intentions. To overcome the above
slowing down, Brainerd is proposing a "tremendous" change to the Fortran
language before core-plus-modules gets working properly. Note that if his
proposed changes occurred after the introduction of core-plus-modules, most of
the "modules" would already be 'frozen' around Fortran 77 and it would be far
more difficult to change them.
There is the implication that the new core language will be "sufficiently
trim that new language features can be added in a natural way" to justify the
tremendous changes he proposes. But he gives very little hard evidence that
the new language will be any better at adapting than the old one. (The case
for removing EQUIVALENCE is well made, but the case for most of the other
changes is omitted. In particular, the removal of COMMON would not be
acceptable to many current users, I suspect).
Difficulties arise:
(a) When the language extension is not "at the same level" as Fortran.
It is a very high level language or is a very low level (perhaps
machine dependent) language.
(b) When the language chosen is otherwise incompatible with Fortran.
i.e. It is non-procedural, requires special data structuring
conventions or conflicts with existing Fortran standards.
Nothing has been said in the proposal about what happens to subset
Fortran.
If this is retained (and presumably the reasons for its existence still
hold), there is a danger of falling into the 'COBOL' situation of having to
support an impossible number of modules and subsets of them.
I suspect that Brainerd intends Fortran Core 82 to be sufficiently
"small" to eliminate the need for a subset. However, there will still logically
be a requirement for a FORTRAN 77 SUBSET MODULE containing redundant features
of the Fortran 77 subset (in the same way as the FORTRAN 77 module would
contain redundant features of full Fortran 77).
We note that the proposal indicates a 'Fortran 77 module' to contain
"redundant" features of the core language (module). If core-plus-modules
were in effect, say module M existed for a special application. Then by 1982
much of M would also be redundant and it would be necessary to create a special
module for redundant features of M, call this M77 as well as the revised
version of M, call this M82.
Each revision cycle would create "double" the number of modules.
Core-plus-modules type changes can only 'evolve' through the mechanism of
'replacement by duplication' (e.g. having F77 as a "module".) - which only
serves to "clutter up" the language, not to "clear it up". (It is argued that
eventually it would 'clear up'. but when?).
General Comments, observations and opinions
Core-plus-modules is being put forward as a general "magical formula" to
all our problems - and tends to obscure some of the real issues - of good
design.
Not enough time has been spent on considering other 'proven' alternatives -
such as the "nested layers" type approach, a "generalisation" type approach
or through the use of preprocessors. It should be noted that no other
language really gains (anything/much) from being structured as a 'core +
modules'.
Core-plus-modules is being used 'to obscure the fact that X3J3 is acting
as a language design team rather than a standardisation one.
Because no implementation of core-plus-modules fortran exists, the whole
process is untested and may be unsound. It is one of the constraints on
standards groups to only adopt well tried methods.
It has been suggested that the X3J3 committee should look at the way that
other software evolves. Mention has been made of the "release" system
used by many organisations such as that used for NAG numerical algorithms.
New releases completely replace old ones and users are expected (and are
able) to revise their programs within a few months usually.
Also consideration should be given to the way that computer manufacturers
update their operating systems - something might be learnt here.
PAC 2 May 79
A "CORE + MODULES" APPROACH
TO FORTRAN STANDARDIZATION
Walt Brainerd
MS 260
Los Alamos Scientific Laboratory
P. O. Box 1663
Los Alamos, NM 87545
U.S.A.
Submitted as a working paper for the 1978 November meeting
of the group of Fortran experts, ISO TC97/SC5
In 1978 January, ANSI X3J3 voted to adopt a framework
consisting of a "core" and "modules" for developing the next
revision of the ANSI Fortran standard. Of course, this is a
decision which could be reversed if the approach appears to be
unsuitable or technically unsound after some experimentation.
However, the approval of this procedure is an indication that the
committee wants to invest considerable effort in an attempt to
make this approach work.
There are at least three reasons for adopting the "core +
nodules" approach:
1) to provide a mechanism to interface with collateral
standards and implementations in major applications areas
2) to provide a mechanism for having optional functional
areas described within the standard
3) to specify a smaller, more elegant, language than Fortran
77 without decreasing the status of Fortran 77 as a
standard language.
Each of these reasons is now discussed in more detail.
One of the major concerns of X3J3 is the development of
collateral standards in areas such as data base management, real
time process control, and graphics. X3J3 does not have the
resources to do the technical development of standards in all of
these areas; in some cases X3J3 may not even be involved directly
in the approval of such a standard. Therefore, it is important
that X3J3 provide a scheme whereby collateral standards in these
applications areas can be regarded as modules in the language that
are "attached" to the core of the language in a standard way. The
only mechanism considered so far for interfacing with these
modules is through the CALL statement, extended to allow the
arguments to be identified by key words. This topic is covered in
more detail in another paper and is an area that can use more good
ideas, because it is a very difficult and important problem.
A second kind of extension might be called a "language
feature module." This sort of module would include a collection of
related language features that might not be appropriate to include
in the core, but which should have its form specified so that all
extensions to the core in this area will be the same. Example
candidates for such modules are array processing, a bit data type,
and specification of numerical precision. Fortran 77 should be
considered to be such a module.
It may be quite inappropriate to add some of these language
features to Fortran 77. For example, it would be rather messy to
add a bit data type or REAL*11 (indicating at least 11 digits of
precision) on top of the Fortran 77 equivalencing mechanism.
For these reasons it is important to design a core that is
sufficiently trim that new language features can be added in a
natural way.
Since Fortran 77 will be one of the modules, the core need
not be constrained to contain all archaic features of Fortran.
One of the design objectives is to eliminate those features (e.g.,
the arithmetic IF statement) that are no longer necessary, due to
the addition of better equivalent features or those features
(e.g., storage association) that actually stand in the way of
adding features recognized as contributing to high quality
programming practices.
To provide just one example illustrating how the storage
association concept impedes the addition of useful features,
consider the possibility of a conditional array assignment.
REAL A(90), B(90), C(90), D(90)
A(*) = 0
B(*) = 0
WHERE (A(*) .LT. 2) DO
C(*) = B(*) + 1
END WHERE
If no equivalencing is allowed, the assignment may be
implemented as
DO 9 I = 1, 90
9 IF (A(I). LT. 2) C(I) = B(I) + 1
However, if the program may contain the statement
EQUIVALENCE (C(1), 8(2))
the loop above will set C(I) = I for I = 1 to 90 instead
of setting each element to 1. The implementation will be more
complex on most machines.
In 1978 August, X3J3 approved a proposal to create a first
cut at a core language by starting with Fortran 77 and making the
following changes. Of course, this list is not final, but is
given to provide a flavor of the final result. When reading the
list of changes, it is important to keep in mind that Fortran 77
will be one of the modules, so any compiler that contains the
Fortran 77 module will be able to process programs containing any
of the features of Fortran 77.
The following two paragraphs are excerpted from the X3J3
proposal to indicate some of the objectives of the approach:
The general philosophy governing this core design is that the
core should be comprehensive, containing virtually all of the
generally useful features of Fortran and that it should form a
practical, general-purpose programming language. Modules would be
used largely for special-purpose language features that entail
high implementation costs or are used primarily in special-purpose
application areas. The number of such modules should remain small
in order to minimize problems of program portability. Three
examples might be (1) a module providing comprehensive array
processing facilities, (2) one providing data base management
facilities, and (3) one providing features of Fortran 77, and
possibly certain other isolated special-purpose features, not
contained in the core.
Another goal is to produce a more elegant language by moving
redundant features and including features which lend themselves to
modern programming practices.
The net effect of these changes is the following
1) Subroutine linkage facilities are enhanced to improve the
interface with applications modules written in Fortran.
2) Archaic control structures are replaced with modern ones.
3) The concept of storage association is removed.
4) Fixed-form source is replaced with free-form source.
There are two kinds of changes: features added to Fortran 77
and features remaining in Fortran 77 but not included in the core.
To be added To be moved to Fortran 77 module
Free-form source Column 6 continuation
Larger character set C for comment
Longer names
------------------------------------------------------------------------
Simple data structures EQUIVALENCE
Some array processing COMMON and BLOCK DATA
Global data definition Passing an array element or
substring to a dummy array
Bit data type Association of ENTRY names
A length (digits) for REAL DOUBLE PRECISION
------------------------------------------------------------------------
Enhanced looping Arithmetic IF
Case construct Computed GO TO
Internal procedures Alternate RETURN
Subroutine linkage ASSIGN and assigned GO TO
Statement functions
ERR = and END = specifiers
------------------------------------------------------------------------
H, X, and D edit descriptors
Specific names for intrinsics
APPENDIX C
Annual Report of BCS Fortran Specialist Group 1978/79
This year has seen the long awaited completion and publication of the
FORTRAN 77 language standard. It has seen too, the start of further revision
for a proposed standard to be completed by 1982. These standards are prepared
by the American National Standards Institute (ANSI) X3J3 committee that is
responsible also for the International (ISO) standard.
The work of our group has been to help collate British opinion on Fortran
proposals and forward these to ANSI X3J3 so that the standards they produce
are acceptable to interested parties in Britain. This has been done in close
liaison with the British Standards Institute. The two main events of this year
have been the meeting in London of a group of Fortran standards experts hosted
by the BSI and including many members of our Specialist Group, and a one-day
Forum on Fortran organised by the Specialist Group at which the Fortran experts
met British Fortran users. We were delighted that 110 people attended this, and
thank Mr. J. Roberts-Jones (Group Secretary) for its organisation, Mr. M. Peltu
(then Editor, Computer Weekly) for publicity and ANSI X3J3 for providing
thirteen speakers and panel members. We were also delighted that Frank Engel
Jr, the Chairman of ANSI X3J3 during the FORTRAN 77 revision period was awarded
Honorary Membership of the BCS for his contribution to Fortran standardisation.
During the year there have also been six committee meetings. Speakers
included Dr. Peter Barker (NUMAC) on "PL/l as a successor to Fortran", Irene
Mallgrave (CRAY computers) on "The Fortran Compiler for the CRAY-l", David
Muxworthy (Univ. Edinburgh) on "Activities of BSI DPS/l3 WG6 and the next
Fortran Standard", Alan Clarke (Rothamsted Experimental Station) on "Using the
Fortran Interface to CODASYL databases", and Dr. Alan Wilson (International
Computers Ltd.) on "Array processing algorithms and the DAP".
Officers elected for 1979/80 are Gary Harding (European Centre for Medium
Range Weather Forecasts) as Chairman and John Roberts-Jones (Liverpool City
Treasury) as Secretary. David Muxworthy (Edinburgh Regional Computing Centre)
was elected vice-chairman.
P. A. Clarke
25th April 1979
BRITISH COMPUTER SOCIETY - FORTRAN SPECIALIST GROUP - 1979/80.
Mr P A Clarke, Harpenden (05827) 62271 X64
Computer Department,
Rothamsted Experimental station,
Harpenden, Herts.
AL5 2JQ
Mr G L Harding, (Chairman) Reading (0734) 85411 X319
European Centre for Medium-range
Weather Forecasts,
Shinfield Park,
Reading, Berks.
RG2 9AX
Dr J D Murchland, 01-657 6478
35, Rectory Park,
Sanderstead, Surrey.
CH2 QJH
Mr D T Muxworthy, (Vice-chairman) 031-667 1081 X2844
Program Library Unit,
Room 2609,
James Clerk Maxwell Building,
Mayfield Road,
Edinburgh.
EH9 3JZ
Mr J M Roberts-Jones, (Secretary) 051-227 3911 X617
Date Processing Division,
City Treasury,
P O BOX 1
Liverpool.
L69 2DQ
Dr A Wilson, Bracknell (0344) 24842 X2419
international Computers Ltd.,
Lovelace Road,
Bracknell, Berks.
RG12 4SN
Mr J D Wilson, Leicester (0533) 50000 X165
Computer Laboratory,
University of Leicester,
Leicester.
LE1 7RH