British Computer Society Fortran Specialist Group
Minutes of a meeting held on Monday 6th December 1976 in lecture theatre
4.34, Royal School of Mines, Imperial College Computer Centre, Prince Consort
Road, London S.W.7.
Present: Mr. D. T. Muxworthy (Chairman) University of Edinburgh
Mr. M. Lewis (Vice Chairman) Imperial College Computer Centre
Mr. A. J. H. P. Dean Honeywell I.S. Ltd (N.I.S.D)
Mr. M. R. Dolbear B.P. (London)
Mr. R. Grosvenor Honeywell I.S.
Mr. P. J. Hanson Honeywell I.S.
Mr. G. Harding Imperial College C.C.
Mr. D. J. Holmes Rolls Royce (1971)Ltd, Bristol
Mr. P. Loftus Marconi Elliott Avionic Systems
Ltd., Rochester
Mr. D. J. Maisey I.C.L. Bracknell
Dr. J. Murchland University College London
Mr. K. Normington Lanchester Polytechnic
Mr. H. Pitcher N.C.C.
Mr. T. L. van Raalte M.O.D.
Mr. J. Roberts-Jones Liverpool City Council
Mr. G. Ruscoe Honeywell I.S. Ltd (N.I.S.D.)
Mr. P. J. Vyse Honeywell I.S.
Dr. H. J. Zell Imperial College
Mr. P. A. Clarke (Secretary) Rothamsted Experimental Station
Apologies for Absence:
Mr. B. H. Shearing Alcock, Shearing and Partners
1. Approval of Minutes of Previous Meeting
The minutes of the meeting of 4th October 1976 were approved subject to
the following corrections:
On page 2, the last word should read 'contentious' not 'contentions', on page 5,
paragraph 1, replace the words 'Emotions with no arguments do not require a pair
of empty parentheses' by 'Subroutines with no arguments may optionally have a pair
of empty parentheses', on page 4 section 4.4, line 2, 'recommending' should read
'recommending' , on page 10 paragraph 5 'on IDMS operation' should read 'an IDMS
operation' and the last coded OBTAIN statement should have an asterisk in column 1.
2. Matters Arising from the Minutes
Since the last meeting, Dr. Stacey has made available copies of the slides
shown during his talk, together with an index of these. They are available on
request from the secretary.
Mr. Roberts-Jones and Mr. Pitcher noted that Appendix A (Block IF statement)
gave no mention of proper nesting of block IFs and DOs. Mr. Clarke explained that
the two page appendix was only part of a re-draft of the complete section on Fortran
control statements, and the nesting rules were present. They had been further
extended by ANSI at the November meeting.
3. Activities of other Fortran Groups
3.1 ANSI X3J3 Activities
Since our last meeting, the minutes of the September meeting of X3J3 had been
received. Mr. Muxworthy discussed some points that had not been fully covered in
our last meeting. These included a proposal to extend names to 8 characters which
had been rejected because it was considered to be too costly for a little benefit.
Discussion of trailing comments, delimited by :* (presumably colon for end of statement
asterisk for comment. This combination would permit a future extension of multiple
statements per line) was postponed until November. Character functions of constant
length are allowed, array block item in I/O lists was deleted because of a syntax clash
with a possible proposal for array cross sections. Mr. Muxworthy suggested this might
be because, as Dr. I.D. Hill had said in June, public comments would tend to emphasise
disapproval and forget to approve of certain welcome features.
The minutes of the November meeting of X3J3 had not been received, but a document
entitled Fortran 77 which summarises the major changes to dpANS (March 1976) since
it's publication had been received from Dr. Meissner (see Appendix A). This
contained some details of decisions made at the X3J3 November meeting, and these were
discussed.
While some people present were against the practice of using extended range of
DO-loops, there was discussion as to the implication of prohibiting extended range.
When a subroutine was called from a statement in a DO-loop, was the RETURN
considered to be transfer of control into the range of the loop? If open-coded
procedures were introduced into Fortran could they be referenced from within a DO-
loop? Open-coded procedures currently implemented by preprocessors (and making use
of assigned or computed GO TO's) and referenced from within DO-loops would become
non-standard. It was decided to wait until the full minutes were available before
taking any action on this point.
The IOSTAT= specifier in I/O statements appeared to offer little advantage over
ERR= and was processor dependent. However, it was thought to be 'in the spirit of
Fortran'.
The functions ICHAR, CHAR and INDEX were considered useful. The fact that
ICHAR could not be used in DATA (or PARAMETER) statements, was a slight restriction -
possibly encouraging programmers to use processor dependent constants, when this was
not necessary.
Dr. Murchland had noted that in the October 1976 Sigplan Notices, the Vice-
Chairman of the ACM Standards Committee had indicated that the ACM Standards Committee
had received only 25 responses to the dpANS (March '76) (of which 14 were in favour.
and 11 against) which was not sufficient to be representative of the ACM membership
and did not justify the publication of Fortrev in Sigplan Journal.
Mr. Clarke noted that BCS Standards Committee had not received any response at
the time of his last contact with Mr. Fisher. Mr. Muxworthy noted that the Fortran
Specialist Group had received only six responses, but that ANSI X3J3 had received
over 600 and he concluded that members of the public had short-cut their local
organisations and sent comments directly to X3J3.
Mr. Lewis said that he had received a newsletter of the CDC Computer Users
Group in which a note by Mr. R. Ragan, a member of X3J3 indicated that the next letter
ballot on the draft standard would probably be in mid 1977.
We had formerly expected this about March 1977.
3.2 Fortran Development Committee
Members had received Vol.2. No.4 of the FOR-WORD Fortran Development Newsletter
This contained copy of the IFIP W.G.2.5 proposals discussed at our last meeting, and
a summary of three data-structuring proposals for Fortran submitted to X3J3 by
Mr. D. N. Smith (Tymeshare Inc.). Also it contains many correspondences from
interested people worldwide. Mr. Clarke recommended that members ask for their names
to be put on the mailing list for FOR-WORD by writing to the Editor, Dr. Loren P.
Meissner, 50B 3259, Lawrence Berkeley Laboratory, Berkeley, CA 94772O, U.S.A. At
present, there is no charge for this.
Mr. Clarke described (with slides) some of the proposals that had been ration-
alised by Dr. Meissner from the many that had been studied in the structured pre-
processor survey. (See Appendix C)
Comments from those present included the following:
Mr. Pitcher said that a single GOTO was simpler than the DO (forever) - ENDDO,
Mr. Maisey asked if Fortran was a suitable language for these statements and was
supported by several other people present when he objected to 'doing-away-with'
labels which these statements tend to make unnecessary. An argument in favour of
Fortran labels was that their use guided the eye to the appropriate text - some of
the block structured statements could be difficult to follow because they require
matching up the begin and end of block and when nested deeply this could be tricky.
Mr. Maisey objected to the inclusion of the statements just for the sake of
'structured programming purists'. He Suggested that they use some other language.
Mr. Dolbear said that structured programming was a language independent concept.
A structured design could be mapped into most procedural languages, with, or without
structured control statements. The presence of structured control statements
simplified the mapping, He recommended the book 'Principles of Program Design' by
M. Jackson, published by Academic Press as an exposition of the ideas of structured
programming.
Mr. Clarke requested that those who felt strongly against (or for) introducing
these statements should write to Dr. Meissner and the views could be published in
FOR-WORD.
3.3 CODASYL Fortran DBML Committee Activities
No further information had been received from the CODASYL FDBMLC. Mr. Clarke
said that because he was aware that there were not many Fortran programmers who
were familiar with the CODASYL database facilities, he had prepared a document
'Introduction to Fortran Database Programming' describing them from a Fortran
viewpoint. A circulation copy is available upon request. He noted that the
FDBMLC JOD was not suitable as an introductory text.
3.4 Other Fortran Groups
3.4.1. Purdue Workshop Activities
The Secretary had received the minutes of meeting of ISA SP61 and IPW Fortran
Committee on 10-12 October 1976. At that meeting there had been discussion of the
S61-1 and S61-2 standards. A draft standard S61-3 on tasking is in preparation
under six headings, Initiation, Synchronisation, Termination, Communication,
Exception, and Critical Regions.
A review of Fortrev had been made and comments on (1) restrictions on COMMON
block of type CHARACTER, (2) extension of PARAMETER, (3) definition of ASSIGN GOTO
with out-of-range argument and (4) keyword specifier EVAL for I/O error value had
been sent to X3J3 and a proposal for type BIT which defines BIT constants, relation
of BIT to INTEGER, relation of BIT to LOGICAL, BIT operations, relational operations
and shift operations.
4. Progress Reports
4.l Preprocessor Working Party
Dr. Murchland reported the following activities:
The preprocessors FLECS (Terry Beyer) and Mortran (A. James Cook) have
now been obtained, the latter by courtesy of Dr. Jack Lang (The Computer
Laboratory, Cambridge). Also available was a structured Ratfor preprocessor.
Now there is a problem in obtaining suitable teat problems! What would Group
members regard as adequate evidence for the merits and demerits of a preprocessor?
Loren Meissner (Lawrence Berkeley Laboratory) had offered us the complete
collection of preprocessor documents which they gathered for the survey they did.
Alan Clarke has offered to keep these at Rothamsted and make them available upon
request.
Dr. Murchland asked if there were any comments on the proposed Fortran pre-
processor statement syntax on page 5 of the minutes of the last meeting? Mr. Clarke
said that the syntax could be extended to include declaration statements and compound
structured statements. The WP are still interested in, and working slowly on, the
original items - terminology for describing preprocessors, a list of available
preprocessors and a list of useful references. The terminology seems to get core
difficult - the preprocessors we have do not provide their standard Fortran output
in a form where it could be distributed as a readable Fortran program.
He said that the W.P. was short of active members, neither Ian McNicol nor
Peter Evans had made a contribution to date and new members to the W.P. would be
welcomed.
4.2 Group Promotion/Information W.P.
Mr. Clarke said that he was still working on the document 'Introduction for
new members' and on the revised Contact List. The new list would include, where
possible, telephone numbers and publications (if any) against each entry.
He requested suggestions as to how to make the contact list more effective
and wondered what use had been made of it to date.
4.3 W.P. to Review the CODASYL FDBMLC JOD
Dr. Stacey had agreed to lead this W.P., Mr. J. S. Knowles (Aberdeen University)
and Mr. P. A. Clarke are the other members. As a result of telephone conversations,
the objective of the W.P. has been narrowed to 'review the JOD from the database
programmers viewpoint' rather than to prepare an introductory description.
5. BCS Business
In the absence of Mr. Shearing, Mr. Muxworthy reported that at the last
meeting of the BCS Specialist Groups Committee. Specialist Groups had been re-
grouped under four headings: Languages, Applications, Transport and General.
This was for publication purposes.
Mr. Muxworthy said that he had written to the BCS in connection with the recent
visit to Great Britain of A. Ershov saying that the Languages Specialist Groups
should have been given the opportunity of arranging a meeting with Prof. Ershov. Prof.
Ershov had considerable experience and interest in computer languages and a
valuable opportunity had been missed.
Mr. Muxworthy had had no reply from the BCS and wondered what was happening.
6. Any Other Business
Details of a BASIC to FORTRAN translation service provided by the National
Development Programme in Computer Assisted Learning (NDPCAL) had been received and
copy can be obtained by interested members, on request, from the Secretary.
Mr. Dolbear had a request for help to check some algorithms for 'floor' and
'ceiling' functions coded in Standard Fortran. Copies were distributed at the
meeting.
7. Date of Next Meeting
The next meeting will be on 7th February 1977.
In the Afternoon, Mr. G. A. Ruscoe (Honeywell Network Information Services
Division) gave a talk on 'Fortran on an International Time-Sharing Network'(see
Appendix B). This was followed by discussion, much of which centred on the
implementation of strings.
[In the original typescript this appendix was presented in two columns
with a small (9pt) font. It has been re-formatted to improve legibility
in a browser window.]
Fortran 77
It appears that a number of individuals and organizations have been
proceeding on the unwarranted assumption that the draft proposed Fortran
standard (SIGPLAN Notices, March 1976) is essentially a correct
description of the final form of the language as it will be ultimately
released by the X3J3 committee. Many implementations of the language so
described are beginning to appear or to be referred to in private and
public distribution, in spite of the disclaimers included in all copies
of the published document.
The purpose of publishing the draft was in no sense to "freeze" the
language specification. On the contrary, the intent was to indicate to
the public the directions of the committee's plans, and to provide a
forum for feedback to permit changes to be made in response to public
review. In the year (more or less) since the text of the draft proposal
was adopted, the committee has made a number of significant changes to
the language. The purpose of this note is to summarize the more
significant of these. For further details, reference should be made to
X3J3 documents containing the minutes of recent meetings (since the
beginning of 1976). These are available upon request from Lloyd Campbell,
whose address appears in the SIGPLAN document.
Name of the language. The committee has adopted the working name
Fortran 77, to be used when informally referring to the language described
by the proposed standard.
Collating sequence. The draft states that letters are in order from A to
Z and digits from 0 to 9, and that blank is less than A and less than 0.
A further restriction has been made, so that the letters and the digits
must not overlap.
Blank lines. It has now been provided that a completely blank line will
be considered a comment line.
Statement ordering. A new restriction applies with regard to symbolic
names of constants (i.e., names defined in a PARAMETER statement) and var-
iables appearing in a dimension bound expression (in a subprogram). These
must not appear in explicit type statements farther down in the same
program unit. Data type of a name. The draft states that the data type of
a symbolic name of a constant (in a PARAMETER statement) is determined by
the form of the constant. This has been changed to depend on the form
of the name.
Scope of names. A clarification has been adopted, to the effect that the
scope of an implied DO variable in a DATA statement is the implied DO
list.
Type restrictions for subscripts etc. Real and double precision
expressions are no longer permitted as subscript expressions, substring
expressions, label selectors for computed GO TO, external unit
identifiers, record number specifiers, record length specifiers, maximum
record length specifiers, or alternate return specifiers. However,
integer expressions that include the INT or NINT intrinsic functions
applied to expressions of other types are permitted.
Intrinsic function names. The draft provided that certain type statements
could change an intrinsic function name to external (i.e., the processor
would expect a non-intrinsic function with the specified name to be
supplied). This has been changed, so that only an EXTERNAL statement can
remove a function name from the intrinsic category in this way.
PARAMETER syntax. Expressions (which may involve symbolic names of
previously defined constants) may be included in the definition of
symbolic constants in a PARAMETER statement. Also, the entire list of
definitions must be enclosed in parentheses. A logical expression used
in the definition of a symbolic name may include relational operators.
New logical operators. Logical operators .XOR. and .EQV. have been added.
Logical operator precedence is .NOT., .AND., (.OR., .XOR.), .EQV. The new
operators represent "exclusive OR" and "logical equivalence",
respectively.
Block IF. The following statements have been added to the language:
IF (e) THEN
ELSE IF (e) THEN
ELSE
END IF
Between an IF-THEN and its END IF there may appear any number of ELSE IF-THEN
statements and at most one ELSE (which must not precede any ELSE
IF-THEN). Blocks delimited by IF-THEN and END IF must be properly nested,
with respect to other such blocks and with respect to DO loops.
Prohibit extended range. Transfer of control into the range of a DO-loop
is now prohibited. Transfer into a block IF structure; or from one
sub-block of the structure to another, is prohibited; however, a transfer
from anywhere to an END IF statement is permitted.
Input and output statements. The Stream access method has been
eliminated. List-directed sequential input and output has been retained
(similar to "format-free" methods that have been implemented);
list-directed output is not suitable for list-directed input, however. An
IOSTAT specifier may be included in any input or output statement
(including auxiliary and file positioning input or output statements), to
permit determination of the cause of an error or end-of-file condition
without a transfer of control. The specifier is IOSTAT = ios where
ios is an integer variable (or array element) that becomes defined with
the value zero if all is well, with a positive integer value if an error
is sensed, or with a negative integer value if no error is sensed but an
end of file is sensed. The specific positive or negative values used
are processor dependent. The ERR = s and END = s specifiers are also
still provided.
The list of "mandatory" error conditions in section 12.6 of the draft
has been replaced by the statement that "the list of error conditions is
processor dependent."
The preconnected units used for the PRINT statement and for the short
form of the READ statement must not be internal files.
Input and output lists. Empty lists are no longer prohibited, since
whatever difficulties they might cause must also be corrected for the
case of zero-trip implied-DO lists.
List items of the "array block" form such as
A(2,3) : A(5,l)
have been eliminated. However, the use of the unqualified array name to
refer to the entire array is still permitted.
A clarification has been adopted, to the effect that implied-DO
variables become undefined when the list items become undefined due to an
error or end condition during input.
Format edit descriptor. The form Gw.dEe has been added, which has the
same effect as Fw.d or Ew.dEe depending upon the magnitude of the datum.
Auxiliary input and output statements. A file that is opened as a scratch
file must not be closed with KEEP status.
An inquiry specifier must not be referenced by any other inquiry
specifier in the same statement (to avoid side effects).
New intrinsic functions for character type. The intrinsic function ICHAR
returns the value of an internal character representation, considered as
an integer. CHAR takes an appropriate small integer and returns the
character having the same internal representation. INDEX returns the
first character position for which a given (short) pattern matches a
substring of a given (long) string.
Other subprogram changes.
The intrinsic functions for type conversion (INT, IFIX, IDINT, FLOAT,
SNGL, REAL, DFLOAT, DBLE, CMPLX) are not permitted as actual arguments.
Character function names may be used as actual arguments.
The generic function name ATAN has only one argument; for two
arguments the generic name is ATAN2.
A statement function of type character, having constant length, is
permitted.
Character strings of "adjustable" length (specified by a non-constant
expression) are eliminated as dummy arguments; however, the "passed"
length (determined by the length of the actual argument) is permitted.
Notes to Table 5 in section 15 have been corrected with regard to the
definitions of the ATAN2 and CLOG functions.
A subroutine with no arguments may be defined with empty parentheses
following the subprogram name. The same applies to an ENTRY statement in
a subroutine.
Loren P. Meissner
50B 3239
Lawrence Berkeley Laboratory
Berkeley CA 94720
22 Nov 1976
Summary of Fortran on an International Timesharing Network
by G. A. Ruscoe
The Network concerned is the Mark III Network Information Service owned and
operated by the General Electric Company of the USA, and marketed in Europe and
Australia by Honeywell. Based on Honeywell 6080 Central Systems the network offers
local access to the same files by local call in Japan, Australia, USA, Canada,
Mexico and most countries of Europe from Spain to Finland and Ireland to Austria.
Although standard Batch Fortran is available on Background Processors, the principal
compiler considered is that specially developed for the Foreground, interactive
service. This has been influenced by certain features of the environment namely:
Terminal use (free-format), Interactive use (conversational or command driven),
Multi-access (shared files, random files), Non-professional use (flexible input,
clear diagnostics), Bias to business applications character handling, data
management, program generation). These factors affect both the programmer and the
user and are reflected in the language features and system routine library.
For the programmer they imply-Free format, line numbered source text; an on-line
debug facility; compiler checking options, and excellent error messages; list directed
input and various types of character variables, especially strings. For the user
there is conversational input which may be flexibly entered and easily
checked by the program; free format data files; programs which appear as additional
system commands or a program which starts at sign-on and controls all operations until
sign-off.
Specific areas of interest are.
l. Shared access to files - implemented by routines which allow shared open with
read access, Lock before write and unlock, Sleep if file busy and Wake if one program
is to interact with another. Identity can be obtained (Part number, user number etc.)
as well as time and date in GMT and user time. Random access to files and a
Hierarchical Indexed Sequential access method are vital to business applications as
are calendar functions, bit manipulation for data packing and picture editing of output.
2. Command system operations - any system command maybe invoked by program, especially
file creation, purge, permission, etc. with status information.
Also programs may be invoked as pseudo-commands, instead of RUN e.g. /PAGELIST FILE1;
FILE2,DW; . . .
The program may read the parameters, read the current file and replace it and generally
act as a normal command.
3. Character handling If one feature characterises the compiler it is the STRING
type. Strings are dynamic (up to 4K characters) with flexible storage allocation and
automatic garbage collection. The language allows assignment and concatenation,
and user string functions. Functions and routines allow efficient string search,
extraction, alteration, conversion to arithmetic value and manipulation generally.
These features allow the passing and vetting of input data, especially on-line input
making due allowance for such factors as use of upper or lower case, inclusion of
excess blanks, abbreviation of words and so on. Many programs, especially pseudo-
commands require a small amount of input which can be made as flexible in form as
possible and where errors are detected the correct input can be prompted. This
revolutionises the user environment. Examples of the use and method of implementation
of strings are instructive.
4. Language extension For many applications the genera1-purpose package has been
superseded by the preprocessor, written in FORTRAN. This takes an application program
in some form and generates a special purpose FORTRAN program, which may be retained
for regular use. Sometimes the application program is a distinct language (e.g. DMS),
Sometimes a form which allows the inclusion of FORTRAN statements (e.g. TABOL).
This form of pre-processor is again heavily dependent on string handling for parsing
the input.
Some proposed control structures for Fortran
The following statements are derived from those published by Dr. L. P. Meissner
in the October 1975 issue of FOR-WORD. The notation 'S' is used to mean a single
Fortran statement or block of Fortran statements and'L' a logical expression. The
control structures are designed to provide control for sequence, selection and
iteration of statement execution. For statements to be executed in sequence, the
statement order is sufficient and no further controlling statements are required.
For selection and iteration, several possibilities are given.
Simple Selection Multiple Character Case Selection
IF(L)THEN CHARACTER MONTH*3
S SELECT(MONTH)
ENDIF CASE('JAN')
S1
Binary Selection CASE('JUN','JUL')
S2
1F(L)THEN ENDSELECT
S1
ELSE Simple Iteration (forever)
S2
ENDIF DO
S
Multiple Binary Selection ENDDO
IF(L1)THEN Conditional Iteration(1)
S1
ELSEIF(L2)THEN DO WHILE(L)
S2 S
ELSE ENDDO
S3
ENDIF Conditional Iteration(2)
Multiple Integer Case Selection DO UNTIL(L)
S
INTEGER MONTH ENDDO
SELECT(MONTH)
CASE(5,6,7,8,9) Generalised Iteration with Interrupts
RATES=SUMMER
CASE(1,11) (NEXT AND EXIT Statements)
RATES=WINTER DO
CASE(12) DO
RATES=XMAS S
OTHER IF(L1)EXIT 99----------------
RATES=NORMAL IF(L2)NEXT 99------------- |
END SELECT S | |
IF(L3)NEXT----------- | |
S | | |
ENDDO <------------------ | |
S | |
IF(L4)NEXT--- | |
S | | |
99 ENDDO <------------------------- |
S <--------------------------------