BRITISH COMPUTER SOCIETY - FORTRAN SPECIALIST GROUP.
MINUTES of a Meeting held at British Computer Society, London, Monday
4th June 1979.
PRESENT:
G L Harding (Chairman) ECMWF
D Bailey University of Salford
M Bereovici University College London
P D Bond Philips Industries
R Chapman Marconi Avionics
I D Hill Medical Research Council
W D Manville GEC Computers Ltd
J D Murchland University of Leeds
R Putra Marconi Avionics
T L van Raalte Ministry of Defence
J D Wilson University of Leicester
J M Roberts-Jones (Secretary) Liverpool City Council
APOLOGIES FOR ABSENCE:
P A Clarke, D Hill, D Muxworthy, A Wilson
APPROVAL OF MINUTES: [2 April 1979]
The minutes of the Annual General Meeting were approved.
FINANCIAL REVIEW:
Final accounts for the financial year 1978/79 were presented. (See
Appendix A). Negotiations with the Secretary-General as to the disposal of the
surplus resulting from Fortran Forum were still proceeding.
[Appendix A was not distributed with the minutes.]
The Secretary presented a summary of the minutes of the October to May
meetings of X3J3. (See Appendix B).
Various comments were made on the proposals for enhanced mechanisms for
argument passing. Several members stressed a requirement that compatibility
checking must be capable of being performed at compile-time. Bailey reported
that the Fortran 77 compiler for the ICL 1900 series being developed at the
University of Salford would in most cases check argument compatibility at load
time; the only run time checks would be on arguments of dummy procedures.
Murchland regretted that X3J3 appeared to be designing a new language
that would have little in common with traditional Fortran implementations; he
felt that many of the changes could he handled by prior use of a macro processor.
On the other hand, Bailey and Wilson thought that Fortran should be taught
strictly in accordance with accepted standards; in a university environment, i1
was not realistic to require use of preprocessors.
Bailey drew attention to the problems of parsing DO statements caused by
the trailing keyword TIMES.
There was discussion as to whether X3J3 were being too ambitious. Hill
pointed out that usually many of the features proposed for inclusion in a
language were eventually excluded. It was felt that at the present stage,
it was right to attempt to evaluate all suggestions. Most members present
thought that the next standard should specify a replacement language rather
than an allegedly evolutionary development of Fortran 77.
Bailey initiated a discussion of an apparently undesirable feature of the
proposals for BIT data type. Consider the effect of:
BIT * 11, A(100)
DO (100 TIMES)
A(8:9) = B'00'
REPEAT
This loop should be capable of efficient implementation, but in practice it
could be grossly inefficient. Because it would be possible to match an actual
bit array with a dummy array having elements of a different length, a compiler
would be obliged to realise A as an array of 1100 consecutive bits if it was
used as an actual argument. Roberts-Jones regretted that this aspect of the
concept of storage sequence association was apparently being retained; what was
required was the flexibility of Pascal, to write:
TYPE bit11 = PACKED ARRAY [1..11] OF [0..1];
VAR a: PACKED ARRAY [1..100] OF bit11;
b: ARRAY [1..100] OF bit11;
...
FOR i:= 1 TO 100 DO BEGIN a[i,8]:=0; a[i,9J:=0 END;
FOR i:= 1 TO 100 DO BEGIN b[i,8]:=0; b[i,9]:=0 END
The first loop economises on storage at the expense of execution time, and the
second allows the compiler to use additional storage to minimise the time.
Murchland was still convinced of the effectiveness of macro processing and
undertook to produce a paper.
[The next meeting was held on 3 September 1979]
Mr W D Manville described the Fortran system implemented on the GEC 4030
series. The system had been developed whilst Fortran 77 was still changing.
He explained the reasons underlying the choice of features for inclusion in the
first release, and described in some detail the method used to evade an
apparent difficulty caused by an idiosyncrasy of the hardware addressing
mechanism.
APPENDIX B - X3J3 ACTIVITY - OCTOBER 1978 T0 MAY 1979.
CLARIFICATIONS.
Various clarifications to Fortran 77 have been formulated - see X3J3/101.
CORE-PLUS-MODULES.
In October there had been considerable debate. It was noted that ECMA/TC8
fully supported the core-plus-modules approach, provided that the core included
the totality of Fortran 77, that all combinations of modules were compatible
and that any functionality common as between modules was defined identically;
they had also suggested that for database interfacing, intrinsic subroutines
should be implemented (with the nature of the arguments being known to the
compiler).
Greenfield had remarked that "the one central attribute of Fortran is
its name".
Olson had been extremely dubious about deletion of features. Fortran
might be archaic and obsolete, but there was a great volume of code still being
used and modified. Fortran was the most portable language, its compilation and
execution were efficient and the language was simple to learn and easy to use.
Fortran 66 compatibility would be demanded for a long time to come.
Brainerd pointed out that many major obstacles had been encountered. whilst
features such as storage sequence sequence association were retained, there
would be grave difficulties in meeting such requirements as for array extensions
and precision specification. The core-plus-modules approach had resulted from
attempts to break the deadlock; if that approach was rejected, the underlying
problems would still be there.
INTERNAL PROCEDURES:
It had been accepted that, particularly now that DO extended ranges had
been abolished, there was urgent need for provision of some form of procedures
internal to a program unit. There had been much discussion as to the scope of
names used in internal procedures. In October, it was decided that the only
names local to an internal procedure would be the names of its dummy arguments
type and dimension declarations for them would be permitted. In January, the
scopes of statement and format labels were discussed but no technical votes
were taken at that meeting.
In March, a provisional specification was agreed. Internal procedures
would appear at the end of the enclosing program unit, and be bracketed by an
INTERNAL SUBROUTINE or INTERNAL FUNCTION statement and an END INTERNAL statement
An IP could contain DIMENSION and type statements in respect of its dummy
arguments. The scope of an IP name would be the enclosing program unit. The
ENTRY statement and alternate return would not be provided. IP's could not
be invoked recursively. Branching into or out of an IP would not be allowed.
FORMAT statements within an IP would not be accessible from without.
Some questions, mainly concerned with scoping rules, were deferred for
subsequent resolution.
ENHANCED PROCEDURAL INTERFACE.
Two distinct types of module had been identified. Language modules would
provide extensions to core Fortran including new statements and syntactic
constructs. Such modules would each add to the size of the language. They
would normally be developed by X3J3. An example would be an array extensions
module.
Procedural modules could be defined in terms of Fortran itself. They would
use Fortran to define new capabilities for Fortran programmers without
increasing the actual size of the language. Such modules might be developed by
groups other than X3J3. Examples might be the ISA standards, mathematical
libraries such as IMSL, SSP and SPSS, and procedural database interfaces.
Procedural modules needed better interfacing tools. There were clear
needs for more powerful procedure specifications, including type definition and
default values for arguments, for additional syntax at the point of call,
including keyword specification of actual arguments, for a name management
mechanism to avoid conflicts between modules, and for an INCLUDE mechanism to
copy in procedure specifications, which would normally be supplied by the
designer of a module and not by its users.
The database working group had requirements for execution time error
handling, for an INVOKE mechanism, for record structures with variants, for
keywords at the point of call, for additional types of actual arguments such as
enumerated sets and implied-DO lists, for variable numbers of parameters, and
default values, for full declaration of external procedures and their arguments
and for parameter consistency checking.
Although various proposals had been considered, no decisions had been
taken so far.
PRECISION SPECIFICATION.
It was accepted that it was necessary to provide for machine-independent
specification of real and complex precisions. A discussion in October had
tended towards specification in terms of decimal digits, so that REAL*10, A
would require that A be held to any precision providing at least 10 decimal
digits. Exact correspondence would be required as between the precisions of
dummy and actual arguments.
An alternative use of REAL*1 for the default precision, REAL*2 for double
precision, etc, was not then liked because it seemed to rule out use of less
than the default precision- However, it appears that such specification in
terms of precision levels is now being favoured.
LOOPING CONSTRUCTS.
X3J3 had examined many possible looping constructs in great detail.
A preliminary decision had been taken, to provide initially one very simple
construct that was capable of extension to include any or all of the other
features investigated and which could if necessary co-exist with Fortran 77
DO loops. Since the new construct was felt to be more regular, X3J3 would in
fact propose to replace the present DO mechanism. The conversion impact would
be slight because automatic translation would be easy.
A loop would have the form:
DO [optional control clause]
DO-block
REPEAT
The construct has an explicit terminating statement to avoid the irregularity
of the present DO loop. A DO-block is a sequence of statements similar to a
block, but it differs from a block in that it may contain loop exit statements,
having the form:
EXIT
Execution of a DO-REPEAT construct implies repeated execution of the
DO-block until the control condition is met or an EXIT statement is
encountered. Execution of an EXIT statement terminates execution of the
innermost containing DO-REPEAT construct.
Initially, three loop control options would be provided, for indexed
looping - DO (i=e1, e2 [,e3]), for unindexed looping - DO (e TIMES), and
for indefinite repetition - the control clause is omitted and execution
continues until terminated by an EXIT statement.
DYNAMIC STORAGE ALLOCATION.
In March, it was resolved that core Fortran should include a limited
dynamic storage allocation facility. That facility would not allow a
programmer explicitly to specify storage allocation at run time. DSA was
needed even for relatively simple array and string operations. Matrix division
seemed to require an amount of temporary storage that could not necessarily be
predicted at compile time. It was proposed that no feature should be discarded
solely because of a DSA requirement.
It was expected that DSA implementation would be transparent to the user,
the only change perhaps being relaxation of the restrictions on character
concatenation.
BIT DATA TYPE.
The May meeting accepted a proposal for a new data type, BIT, which would
be similar to data type CHARACTER but manipulating strings of bits instead of
strings of characters. Bit strings would, however, be aligned to the right.
A type statement BIT would correspond to the CHARACTER statement and have
similar syntax. Bit substrings would be provided. operations on bit operands
would be //, .NOT., .AND., .XOR., .OR., and comparisons (.LT. etc). There
would be a bit assignment statement. Bit constants could be denoted as strings
of binary octal or hexadecimal digits (B'111010', O'72', Z'3A').
Various transfer functions are proposed, between logical and bit types,
and between bit and integer types (with specification of the required sign
convention). Intrinsic functions would provide for logical and circular shifts
and for counting the number of one bits in a string. There would be variants
of the LEN and INDEX functions.
LONGER NAMES.
The May meeting resolved to allow names of up to 31 characters, all
characters of a name contributing to its uniqueness. This brings Fortran into
line with PL1 and ADA; Cobol allows 30 characters, as do Codasyl schemata.
The underscore character will be allowed in names, but not as the first.
LOWER CASE ALPHABET.
If both upper and lower case alphabets are available, the two cases are
to be equivalent except in character constants and in H and apostrophe edit
descriptors.
IMPLICIT NONE.
This statement may be used to cancel implicit typing, so that all names
except those of intrinsic functions must be typed explicitly. No other
IMPLICIT statement may appear in the same program unit.