British Computer Society Fortran Specialist Group
Minutes of the meeting held on Monday 16th May 1977 in lecture theatre 4.34
Royal School of Mines, Imperial College Computer Centre, Prince Consort Road,
London SW7.
Present: M Lewis (Chairman) I C C C
P A Clark Rothamsted Experimental Station
C R Clayton I C L
M R Dolbear B P (London)
J L Dyke Huntingdon Research Centre
J A Elliott B A C Weybridge
J Gilbert U L C C
J Greenaway I C C C
R Grosvenor Honeywell I S
I R Harrison Honeywell
J B Haseler G C H Q
D Hill C C A
D J Holmes Rolls Royce Ltd., Bristol
G Horsnell I C C C
N W James I C C C
M G Johnson U L C C
C Lazou U L C C
P Lottus Marconi Elliot Avionic Systems Ltd(GEC)
B Meek Queen Elizabeth College, London
J D Murchland University College London
A J Osborn I C L
T L van Raalte M O D(A W R E)
J Reynolds Imperial College, London
J Roberts-Jones Liverpool City Council
G A Ruscore Honeywell I S
J L Schonfelder C C University of Birmingham
R S Scowen N P L
K Tuckel School of Pharmacy
P J Vyse Honeywell
J M Watson I C L
J D Wilson University of Leicester
J Zell I C C C
G L Harding (Secretary) I C C C
1. Approval of Minutes of previous meeting
The minutes of the meeting of April 4th 1977 were approved.
2. Matters arising from the Minutes
A request was made for volunteers to fill a vacant post on the steering
committee. After the meeting two people came forward and will be considered
at the next meeting.
3. Activities of other Fortran Groups
3.1 ANSI X3J3 committee activities
Mr Lewis read through a summary of actions in response to public
comment received from X3J3(Appendix A). Some items raised comment but
generally most were approved of.
3.2 Fortran development committee activities
No information had been received since the last meeting.
3.3 BSI DPS 13 WG 2 (Programming languages for industrial control, systems
and communications)
Mr Clark reported that he had heard from Dr Rutherford in early April
on the progress of the survey of usage of 'Industrial Fortran' (i.e. ANS
Fortran with ISA routines). At that time Dr Rutherford had received 40
replies.
The current position (12th July) is that 53 replies have been received
of these 44 are from computer users, 2 from U.K. manufacturers and
7 from US based computer manufacturers. Of the 44 computer users 27
are Industrial/Commercial and 17 are Government/Research. Fifteen (15)
of the the users and eight (8) of the manufacturers were aware of the
ISA standards. Seven (7) of the users use ISA standard facilities, twenty
use very similar facilities and of the remaining seventeen, twelve do
not use Fortran and five were not involved in real time.
Dr Rutherford had attended the last BSI DPS 13 WG 2 meeting and had
faced the criticism that his survey only related to historical facts and
did not indicate what facilities users would like.
From discussions with members of the BSI working group and his own
experiences Dr Rutherford thinks that the short coming of Fortran for
some real-time work is that it is not as efficient in its use of time
or storage as Coral 66 or RTL/2. The main reason for this is the large
overhead caused by the Fortran run-time facilities, particularly Input and
Output. Also. partly for the same reason, there is less user control i.e.
time and core requirements are less predictable.
4. Working party reports
There were no new activities.
5. Other recent Fortran events
5.1 Implementation developments
A brief mention was made of an article in SIGPLAN Vol.12 No.4(April 77)
on CDC Star Fortran.
We have received two documents from Lancaster Polytechnic describing a
Fortran compiler written there to run on an ICL 1903S under George 3.
This contains some features of Fortran 77 such as the block IF statements.
It was mentioned that GE/HONEYWELL are advanced in an implementation
of Fortran 77.
5.2 Fortran Publications
Dr Murchland mentioned the many articles in SIGPLAN Vol. 12 No. 4
(April 77) that were of interest to members of the group. These included
"Structured Fortran - with or without a preprocessor" by David E Boddy and
"DYNOSUR, A set of subroutines for dynamic memory organization in
FORTRAN programs" by N Huyhrechts.
6. BCS Business
6.1 Datafair 77
The group will be giving a presentation at Datafair 77 on Wednesday
5th October between 4.15 and 5.45.
7. Any Other Business
There was no other business.
8. Date of next meeting
The next full meeting of the group will be on November 14th.
Afternoon
Mr Richard Ragan of CDC and the X3J3 committee gave a talk on Fortran 77
a summary of which is attached.
[Also attached:
Summary of X3J3 Actions in Response to Public Comment
List of Major Differences from ANS X3.9-1966 FORTRAN
FSG Annual Report l976/77]
Summary of a Talk on the Draft Proposed ANSI FORTRAN by Mr. Richard
Ragan (Control Data Corporation)
All substantive changes to the draft proposed ANSI FORTRAN standard
were completed at the March meeting of X3J3. The May meeting will
deal with the remaining editorial issues and approval of the responses
to public comments document.
A survey of the major new features in FORTRAN 77 includes:
character data type, IF-THEN-ELSE for structured programming,
extensions to array usage to allow more dimensions and lower bounds,
relaxation of restrictions on the DO and deletion of the extended
range, mixed type arithmetic, numerous I/O extensions including OPEN,
CLOSE, INQUIRE, direct access I/O and list directed I/O. a number of
new intrinsic functions, multiple routine entries and alternate
RETURN's, PARAMETER, IMPLICIT, and SAVE statements.
From an implementor's viewpoint the most significant item (i.e.
most difficult) is the character data type. It affects almost all
areas of the compiler and run time library. Other areas with non-
trivial impact include the PARAMETER statement and run-time routines
for OPEN, CLOSE, INQUIRE, list directed I/O, and direct access I/O.
IF-THEN-ELSE is relatively easy to add.
A problem area is the zero trip DO. While easy to implement, it is
counter to the defacto practice of one trip loops. Therefore, it is
felt that an option for one trip DO loops must be provided to aid user
transition.
Initialization of character entities by a DATA statement may be a
problem for word oriented machines. Usually the loader on such
machines provides for initializing only whole words. Therefore,
loader extensions may be required.
With respect to architecture of a compiler for FORTRAN 77, Control
Data feels that there are two major classes of users the compiler must
satisfy: 1) fast compile and no optimization (universities and time
sharing service usage) and, 2) slow compile to obtain maximum
optimization (production usage). The CDC compiler for FORTRAN 77
attempts to meet both goals with a single compiler.
Fast compile mode is a single core load (non-overlayed) compiler
with a minimum code generator. If high optimization is selected the
fast mode compiler which contains the syntactic and semantic
processors for the language simply produces an intermediate language
tile (instead of object code). Then another overlay containing the
global and local code optimizers is loaded to process the intermediate
language file and produce object code.
This structure has the advantage of a single language front end for
a fast and an optimizing code generator. with a single front end
maintenance and enhancement costs are cut in half over the two
compiler situation.
X3/77-69
ATTACHMENT B
Summary of X3J3 Actions in Response to Public Comment
The following is a summary of X3J3 actions in response to public comment
on the draft proposed revised FORTRAN standard X3J3/76 published for public
review in March 1976.
A number of public comments resulted in X3J3 actions to change the draft;
others resulted in X3J3 actions affirming the features of the language sub-
stsntislly as described in the draft. These two groups of items ere listed
separately in this summary.
It should he noted that the draft proposed standard describes two levels
of the FORTRAN language. All changes made to the full language in response to
public comment were carefully reviewed for their applicability to the subset
language, and where necessary appropriate action was taken by X3J3 to change
the subset as well. Items in this list marked (*) involved changes to the
subset language as well as to the full language.
Part 1. Actions resulting in changes to the March 1976 Draft
* l. Further restrictions on collating sequence. The letters A - Z and the
digits 0 - 9 must not overlap in the collating sequence. This restriction
use not included in the Draft.
* 2. Blank lines. A completely blank line among the lines of a program unit
is considered to he a comment line. Formerly it was the initial line of s
statement.
* 3. Statement ordering. A further restriction was adopted, to the effect
that symbolic names of constants, or variables appearing in dimension hound
expressions, must not he explicitly typed farther down in a program unit.
* 4. Form of a constant. The rules were relaxed to permit an integer con-
stant (as well as a real constant) as either pert of a complex constant.
* 5. Data type of a symbolic (PARAMETER) name. Type rules for PARAMETER
statements are changed, so that the type of the symbolic name of a constant
depends upon the form of the name rather then upon the form of the constant.
* 6. Character length for a symbolic (PARAMETER) name. A symbolic name for
e constant of character type may he declared in a CHARACTER statement with s
length specification consisting of an asterisk. The actual length for such
s symbolic name is determined from the length of the character constant in
the PARAMETER statement. This way of specifying length was not provided in
the Draft.
* 7. Restriction to integer type, for subscripts etc. In a number of places
where the Draft permitted integer, real, or double precision expressions,
only integer expressions are now permitted. These are: subscript expres-
sions, substring expressions, label selectors for computer GO TO, external
unit identifiers, record number specifiers, record length specifiers, end
alternate return specifiers.
* 8. Intrinsic function names. The Draft provided that certain type state-
ments could change an intrinsic function name to external. This has been
changed so that only an EXTERNAL statement can remove a function name from
the intrinsic category in this way.
* 9. PARAMETER syntax. The following changes were made to the Draft:
An expression, which may include symbolic names of previously defined
constants, may he included in the definition of a symbolic constant in a
PARAMETER statement.
The entire list of definitions must he enclosed in parentheses.
* 10. Exponentiation. An integer, real, or complex expression may be raised
to a real or complex power. Complex exponentiation was prohibited in the
Draft. Rules have been included to determine the principal value of the
result.
Exponentiation with integer powers is now permitted in an arithmetic
constant expression.
* ll. Logical operators. Two logical operators were added to those described
in the Draft. These are .EQV. and .NEQV. , and both of these operators have
lower precedence than any of the previous logical operators. If L1 and L2
are logical expressions, then Ll .EQV. L2 is true when Ll and L2 ere both
true or both false, and Ll .NEQV. L2 is true when one is true and the other
is false.
* 12. SAVE statement. The following changes were made to the Draft:
An integer variable specified in a SAVE statement, that is defined with
a statement label value, no longer becomes undefined upon return from a pro-
cadure.
When a labelled common block is specified in a SAVE statement in one
subprogram of an executable program, the block must be specified in a SAVE
statement in every subprogram in which it appears.
* 13. DATA statements. The rules for correspondence between the list of names
and the list of constants were relaxed, so that an entity of complex type
(as well as integer, real, or double precision) in either list may correspond
to an entity of any of these types in the other list.
* 14. Block IF. The following statements were added to the language:
IF (e) THEN
ELSE IF (s) THEN
ELSE
END IF
For each IF-THEN statement there must be a corresponding END IF state-
ment. Between the IF-THEN and the corresponding END IF there may appear any
number of ELSE IF-THEN statements, followed by at most one ELSE. Groups of
statements delimited by IF-THEN and END IF must be properly nested, with re-
spect to other such group of statements and with respect to DO loops.
* 15. Restrictions on transfer of control. The following rules were adopted:
Transfer of control into the range of a DO loop is prohibited.
Transfer into a group of statements delimited by IF-THEN, ELSE IF-THEN,
ELSE, or END IF, from outside the immediate group, is prohibited. However,
transfer to an END IF statement is not prohibited.
l6. Input and output statements. The following changes were made:
An IOSTAT specifier may be included in any input or output statement
(including auxiliary and file positioning input or output statements) to per-
mit determination of the cause of an error or end-of-file condition without
requiring a transfer of control. (The ERR = and END = specifiers are retained.)
* An asterisk may be used as a unit specifier in a WRITE statement, or in
a READ statement that contains a control information list. The asterisk
identifies the same processor-determined external unit (which must be precon-
nected for sequential access) that is used for a PRINT statement or for a
READ statement without a control information list, respectively.
* An empty list is no longer prohibited.
The "array block" list item form was deleted. (An unqualified array
name is still permitted.)
l7. Input and output errors. The following changes were made:
There are no longer any "mandatory" errors that must be treated as errors
by all standard conforming processors. Instead, the list of error conditions
is processor dependent.
When an error or end condition occurs during an input or output opera-
tion, any implied-DO variables in the input or output list become undefined.
18. File properties. The following changes were made:
The Stream access method is no longer provided.
* A file may have more than one allowed access method (Sequential or Di-
rect) and more than one allowed form (Formatted or Unformatted). However,
for any connection at most one access method and one form are established.
* 19. Connection properties. Properties formerly associated with a file are
now properties of a connection between a file and a unit. This includes the
following:
An access method (Sequential or Direct) is established for the connection.
A form (Formatted or Unformatted) is established for a connection to a
file that exists. (Note that a Sequential connection to a file that exists
now has a form property.)
A record length is established for a connection whose access method is
Direct.
A blank significance property (ZERO or NULL) is established for a con-
nection whose form is Formatted. If the connection results from execution
of an OPEN statement that does not explicitly specify a blank significance
property, the default is BLANK = NULL.
* 20. Auxiliary input and output statements. The following changes were made:
New specifiers SEQUENTIAL, DIRECT, FORMATTED, and UNFORMATTED were added
to the INQUIRE statement to provide information concerning the act of allowed
access methods and the set of allowed forms for a file.
* The MAXREC specifier is no longer included in the OPEN and INQUIRE
statements.
A BLANK specifier is now included in the INQUIRE statement, to permit
determination of whether the currently established blank significance prop-
erty is ZERO or NULL.
An inquiry specifier must not be referenced by any other inquiry speci-
fier in the same INQUIRE statement (to avoid side effects).
A file that is opened as a scratch file must not be closed with KEEP
status.
21. Records. The following changes were made:
Records written by a suitable explicit format may be read by list-direc-
ted formatting.
* The length of an unformatted record is measured in processor-dependent
units. If the list of an unformatted WRITE does not fill the record on a
file connected for direct access, the remainder of the record in undefined.
* In a formatted record, a value corresponding to an input list item of
logical type may contain an optional period before the T or F (so that the
logical constant forms .TRUE. and .FALSE. may be used as input values). For
list-directed input, the input form corresponding to a list item of complex
type may have blanks before or after the real or imaginary pert.
22. Format specification. The following changes were made:
* Negative zero is prohibited in the exponent field for E and D output.
* The form Gw.dEe was added which has the effect of Fw.d or Ew.dEe
depending upon the magnitude of the datum. The form Ew.dDe was removed,
but Ew.dEe was retained. [In the subset language the forms Ew.dEe and
Gw.dEe, which did not appear in the Draft, were added.]
The forms +nX and -nX were changed to TRc and TLc respectively. TLc
has exactly the same effect as nX, if c and n have the same values. Neither
effects the output record length.
23. Intrinsic functions. The following changes were made:
Intrinsic functions ICHAR and CHAR were added, to provide conversion of
a character to an integer and vice versa. The pattern matching function
INDEX was also added.
* REAL is now permitted as a specific intrinsic function with integer ar-
gument. (This should encourage use of REAL and INT instead of FLOAT and
IFIX in the subset language). REAL with a complex argument must now be con-
sidered a generic intrinsic function. DBLE is retained as a generic function
only; DFLOAT is eliminated entirely.
* The type conversion functions (INT, IFIX, IDINT, FLOAT, SNGL, REAL,
CHAR, ICBAR) are no longer permitted as actual arguments.
* The intrinsic function SIGN is no longer undefined when its second arg-
ument is zero; its value is now defined as the absolute value of the first
argument.
* The generic arctangent function with two arguments was changed to ATAN2.
* The definitions of ATAN2 and CLOG were corrected.
24. Subprograms involving character data type. The following changes were
made:
Character function names may now he used as actual arguments.
A statement function of type character, having constant length, is now
permitted.
Character strings of "adjustable" length (specified by a non-constant
length expression) ere now prohibited as dummy arguments. However, the
"passed" length (determined by the length of the actual argument) is retained.
The length specification for a statement function dummy argument of
character type must be an integer constant expression.
25. Other subprogram features. The following changes were made:
* An asterisk is permitted as the upper dimension bound for the last di-
mension of a dummy array. The "assumed size" of such a dummy array is de-
termined from the size of the actual argument array.
If a function subprogram contains ENTRY statements, a reference to one
of the function procedures defined by the subprogram must not cause defini-
tion of an associated function procedure name (as a variable) of a different
type.
* A subroutine with no arguments may he defined with empty parentheses
following the subprogram name. The same applies to an ENTRY statement in a
subroutine. The parentheses in a FUNCTION statement are mandatory even if
there is no argument list.
26. Scope of a name. The scope of the name of an implied-DO variable in
a DATA statement was not specified in the Draft. The scope of such a name
is now specified to be the implied-DO list.
Part 2. Actions resulting in no change to the March 1976 Draft
During the processing of public comments, proposals were rejected by the
committee which would have made the following changes to language features
described in the Draft published for public review in Hatch 1976:
1. Arrangement of statement lines.
Permit more than one statement to be written in the sequence of an ini-
tial line and its continuation lines, with a semicolon between statements
and an optional semicolon at the and.
Permit a # character on any initial line or continuation line except an
initial line that contains an END statement. Characters on the line to the
right of the # would be treated as a comment.
2. Longer symbolic names.
Permit variable names up to 8 characters in length.
Permit variable names, array names, end symbolic constant names up to
16 characters in length.
3. Alternative forms for logical constants.
Permit .T. and .F. as alternative forms for logical constants.
4. Additional data types.
Add Double Precision Complex data type, or Bit data type, to FORTRAN,
along with the necessary intrinsic functions, etc.
5. Different substring syntax.
Change the notation for a substring of an array element, by placing the
substring specifier inside the parentheses that delimit the subscript, with
the substring specifier preceding the subscript expressions.
Change the substring specifiers to first character and substring length,
instead of first character and last character.
Replace the parentheses that delimit the substring specification, with
angular brackets < and > .
6. Integer DO variables.
Require that a DO variable be of integer type, and that the DO loop
parameters be integer expressions.
7. Expressions _and Assignment.
Provide .NG. and .NL. relational operators, as alternatives to .LE.
and .GT. respectively.
Provide .XOR. logical operator, with the same precedence as .OR.,
instead of .NEQV.
Permit "full array references" (of the same form as an array element
reference, but with asterisks in place of subscript expressions) on the
left side, and in the expression on the right side, in an assignment state-
ment. All dimensions would be required to match throughout an assignment
statement containing such references. The right side would be prohibited
from containing scalars or other entities partially associated with the
array on the left. The interpretation would be equivalent to a sequence
of arithmetic assignment statements, one for each of the elements of the
arrays so referenced.
8. Control statements.
Delete the assigned GO TO statement (hut retain statement label assign-
ment for use with FORMAT statements).
Delete the keyword THEN from the block IF and ELSE IF statements.
Add CASE, WHILE, or UNTIL statements.
Change the minimum DO loop iteration count from zero to one.
Delete the alternate return feature in subroutine calla.
Provide an internal procedure mechanism (within a program unit).
9. Input and output.
Prohibit execution of an OPEN statement specifying a unit that is
already connected.
Permit a RECL specifier, to establish e maximum record length, in an
OPEN statement for a sequential connection.
Provide the NAMELIST input and output features.
Provide the R edit descriptor.
10. Additional intrinsic functions.
Add the intrinsic functions EPSLN, INTXP, and SETXP, to provide infor-
mation concerning precision parameters of the host computer.
Add the VERIFY function with two character string arguments, which is
true if each character of the first string is also present in the second.
Add "lexical comparison" functions of logical type, one of which is
true if the first argument precedes the second in the ASCII collating se-
quence, and the other one of which is true if the first argument follows
the second in the ASCII collating sequence.
Add complex trigonometric intrinsic functions CTAN, CSINH, CCOSH, CTANH.
Add a one-argument sign function SIGNUM, whose value is -1, 0, or +1
according as the argument is negative, zero, or positive.
List of Major Differences from ANS X3.9-1966 FORTRAN
The following is a list of major differences between the draft proposed
FORTRAN standard (Document X3J3/90) and the previous standard, ANS X3.9-1966.
An extremely important consideration in the preparation of the draft pro-
posed standard was the minimization of conflicts with the previous standard.
The differences listed here represent (with only two exceptions, noted below)
extensions to, rather than conflicts with, the previous standard.
It should be noted that the draft proposed standard describes two levels
of the FORTRAN language, referred to as FORTRAN (the full language) and subset
FORTRAN. Differences noted in this list refer to the full language.
1. "Structured" branching statements. The following statements have been
added to the language:
IF (e) THEN
ELSE IF (e) THEN
ELSE
END IF
For each IF-THEN statement there must he a corresponding END IF statement.
Between the IF-THEN and the corresponding END IF there may appear any number
of ELSE IF-THEN statements, and at most one ELSE (which must not precede any
of the ELSE IF-THEN statements). Groups of statements delimited by IF-THEN
and END IF must be properly nested, both with respect to other such groups and
with respect to DO loops. Transfer of control into such groups is prohibited.
2. Character data type. A new data type, consisting of character strings of
fixed declared length, has been added to the language. Included are character
constants, character variables, and arrays of character data. Operations on
character data include concatenation and designation of substrings. Intrinsic
functions for conversion between single characters and small integers, for pat-
tern matching, and for determining the length of a string are included.
The Hollerith data type of ANS X3.9-1966 has been deleted. Because this
introduces a conflict with the previous standard, it is anticipated that some
processors will wish to retain Hollerith data as an extension to the new stan-
dard; accordingly Appendix C (Section 21) of the draft proposed standard con-
tains recommendations for the form such an extension should take.
3. DO loop changes. A DO statement specifying a terminal parameter whose
value is less than that of the initial parameter is no longer prohibited. If
the incrementation value is positive, such a statement specifies a loop to be
executed "zero tines." Negative increments are also permitted. The DO var-
iable remains defined at completion. Transfer of control into a DO loop is
prohibited (in conflict with the previous standard).
4. List-directed input and output. A form of input and output is provided,
which does not require an explicit format specification. The form of the ex-
ternal representation is determined by the input or output list items.
5. Expressions. An arithmetic expression may include subexpressions of more
than one type. (If an operator has two operands of different types, the oper-
and whose type differs from that of the result is converted before the operator
is applied.) A subscript expression may be any integer expression. A DO par-
ameter may be any expression of integer, real, or double precision type.
6. Compile-time constants. A PARAMETER statement has been provided, which
declares the value corresponding to the symbolic name of a constant. Such a
name may be used in an expression, in a DATA statement, or in following PARAM-
ETER statements.
7. Implicit type declaration. An IMPLICIT statement may he used to declare
implicit types for variables and array names beginning with certain letters.
8. Generic intrinsic functions. Many intrinsic (predefined) functions pro-
duce a value whose type depends upon the type of the function arguments.
9. Subprogram reference. Subroutines and functions may contain ENTRY state-
ments, and subroutines may have alternate returns.
10. Array bounds. An array declaration may include both upper and lower
subscript bounds; if only one of these is specified, the default lower bound
is one. Arrays may have up to seven dimensions. The upper dimension bound
for the last dimension of a dummy argument array may be an asterisk, designa-
ting that the size af the array is to be determined from the actual argument.
ll. Computed GO TO default. If the control expression of a computed GO TO
is out of range, execution continues with the statement following the computed
GO TO.
12. Input and output statements. The following features have been included:
An output list may contain constants and expressions.
An input or output statement may contain a character string to be used as
the format specification.
End and error condition control for input and output are provided.
Tab edit descriptors have been added for format specification.
Direct access input and output have been provided.
A character array may be used as an internal file.
OPEN, CLOSE, and INQUIRE statements are included.
13. SAVE statement. Values of entities in a subprogram may be preserved dur-
ing the time when the subprogram is no longer being referenced, if the names
of the entities are specified in a SAVE statement.
14. FORTRAN character set. The apostrophe and the colon are added to the
FORTRAN character set. The collating sequence is only partly specified.
15. Comment lines. An asterisk or a C in column 1 designates a comment line.
BCS Fortran Specialist Group Annual Report l976/77
Throughout the year, the Group has continued its main activity of
discussing and putting forward a British viewpoint on Fortran Standards.
In particular, much time has been spent studying and commenting on the
draft proposed ANS Fortran (published March 1976). A collection of British
comments on this was sent to the ANSI X333 Fortran Committee. Some of these have
since been incorporated into the draft.
The group has been in contact with other committees related to the
development of Fortran. These include the ACM SIGPLAN Fortran Development
Committee. Several of our Group members have contributed to the FOR-WORD Fortran
newsletter produced by this committee.
There has been continued study of the CODASYL Fortran Database
Manipulation Language committees draft Journal of Development and a working
party has been set up to make a critical review of the finalised Journal.
Contact has been kept with the Dutch Fortran Study group, and their
proposals have been discussed at meetings.
The International Purdue Workshop's Fortran Group and the Instrument
Society of America's SP6l committee have been revising the ISA S61.2 standard
which defines procedures for use with Fortran in application areas such as real-
time process control and instrumentation. The group has studied these. Contact
with the Fortran Committee of ECMA and the newly formed Fortran Working_Group of
the Canadian Standards Association has been maintained.
Members of the Group have served on the BSI DPS/13 committee's working
groups (a) to comment on the draft proposed ANS Fortran Standard (I.D. Hill,
(chairman), A.C. Day, P. A. Clarke) and (b) advise on the position of Fortran
for standardisation of languages for real-time processing (D.A. Rutherford).
The working party on Preprocessors (Chairman, J.D. Murchland) drafted some
recommendations for preprocessing conventions.
There have been five meetings during the year at which speakers have
included Dr. I.D. Hill on 'Language Standards and Algorithm Editing', Dr. G. M.
Stacey on'Experiences with a CODASYL database system', Mr. G. Ruscoe of
Honeywell on 'Fortran on an International Time-Sharing Network', Dr. A. Sambles,
Dr. B. Ford and Mr. S. J. Hague on different 'Aspects of large scale Fortran
projects'.
Membership has increased from about 150 to 190. D. T. Muxworthy and P. A.
Clarke have been succeeded by M. Lewis and G. Harding as chairman and Secretary
respectively and D. T. Muxworthy succeeds M. Lewis as vice-chairman for 1977/78.
P. A. Clarke
11th July, 1977