BRITISH COMPUTER SOCIETY - FORTRAN SPECIALIST GROUP
MINUTES OF MEETING HELD AT BCS HQ, MANSFIELD STREET, LONDON ON 10 DECEMBER 1984
Present: M J Appleford - The Ove Arup Partnership
D Bailey - Salford University
L Devaney - LB Ealing
M R Dolbear - BP International, London
J L Dyke - HRC
T M R Ellis - Oxford University
M L Ellnor - BICC Research and Eng Ltd
W Flexner - Retired
D T Griffiths - System Software Factors
B R Hogg - British Gas
D Lambert - MOD, DOAE
Chris Lazou - University of London Computer Centre
Brian Meek - Queen Elizabeth College
David Muxworthy - University of Edinburgh
K Normington - Coventry Polytechnic
Mike Nunn - CCTA
A R T Ormsby - University College of Wales, Aberystwyth
E G Reilly - BSRA
N W Smith - British Gas
B Steiner - Bacon and Woodrow
D Vallance - Salford University
Dr H Walters - BICC Research and Eng Ltd
D Watkins - UMIST
Alan Wilson - ICL
John Wilson - Leicester University
Addresses:
Chairman John Wilson
Computer Laboratory
University of Leicester
LEICESTER
LE1 7RH
Secretary Mike Nunn
CCTA
Riverwalk House
157 Millbank
LONDON
SW1P 4RT
Treasurer Keith Normington
Computer Centre
Coventry (Lanchester) Polytechnic
COVENTRY
CV1 5PB
1. APOLOGIES FOR ABSENCE
Apologies were received from John Reid (Harwell) and Lawrie Schonfelder (Liverpool
University).
2. MINUTES OF LAST MEETING [10 September 1984]
The minutes were accepted.
3 MATTERS ARISING
Draft BSI standard document "Method for Specifying Requirements for FORTRAN
Language Processors".
BSI have totally re-written this in their own english style. It is expected
to be accepted at their mid-December meeting and then go out for public comment.
It will be published in BSI News, but this is unlikely to be widely seen in
the Fortran world. David Muxworthy, a member of the BSI committee, will try to get
copies for the BCS Fortran Group. Appendix A of these minutes contains the front
page of the draft document. Anyone wishing to receive a copy of the full draft should
write to:
A J Williams
British Standards Institute
2 Park Street
LONDON
W1A 2BG
Cost is £3.50.
4. BCS BUSINESS
(i) BCS Specialist Groups Board.
Two recent meetings had taken place which were attended by our
Chairman. Main items of interest were:
(a) A proposal to offer non-BCS members an "affiliate"
membership at £14-15 pa.
(b) Dr Barber has retired and Mr d'Agapeyeff has taken
over his duties as Vice-President.
(ii) A BCS congress is being organised from 29-31 March 1985 to discuss
the future of the Society and each Specialist Group is being asked
to send 2 representatives. Agenda and timetable are in appendix B.
Anyone interested in representing the Fortran Group should contact
John Wilson.
(iii) Budgets submitted by Specialist Groups are more than the total
funds available so there will probably be some cutbacks in
allocations.
(iv) A new Specialist Group called "Computational Physics" is being
formed. Anyone interested should write to the organiser,
Peter Marcer, 65 Wellsway, Keynsham, Avon. [see appendix F].
John Reid has kindly supplied a report on the 12-16 November meeting of X3J3 in
Fort Lauderdale (see appendix C). In John's absence Alan Wilson gave his
impressions of the X3J3 meeting:
(i) X3J3 is working on S8 document (defining the content of "8x")
which it hopes to have ready for public review a year hence.
(ii) BIT data type - is now back in "8x"
(iii) WHILE statement - until the X3J3 meeting before last was not a
feature being considered but was then voted in.
But at the Florida meeting was taken out.
(iv) Applications Module - this is the latest evolutionary stage of
the core and modules concept. It has
facilities replacing F77 concepts. Amoco
wanted a standard module for fast Fourier
transforms.
(v) Exception handling - still some way to go before finalisation.
(vi) Source form and significant blanks - some confusion in this area
and eventuality is uncertain.
Anyone with comments on the proposed content of "8x" can forward them via
Alan Wilson, John Reid or Lawrie Schonfelder who regularly attend X3J3
meetings as UK representatives.
6. FORTRAN FORUM
Following the X3J3 meeting in Oxford next summer there will be a Fortran Forum
in London on Monday 15 July. John Reid is arranging the agenda which will include
leading members of X3J3 talking about the content of the next Fortran Standard
"8x". Our Group is hoping for an attendance of about 100-150. Coffee,lunch
and tea will be provided. The fee for attending is still to be decided but will
be notified in the newsletter accompanying the minutes of our next meeting which
will also contain a booking form.
7. ANY OTHER BUSINESS
The Group would welcome suggestions on topics for talks in the afternoons at
future meetings. Anyone with ideas please complete appendix D and return to the
Secretary.
8. DATE OF NEXT MEETING
The next meeting of the Group will take place on Monday 11 March at BCS HQ from
lO.45am to 4pm. It will include the AGM. In the afternoon there will be a
talk on "DEC Fortran compilers and program development aids" by a speaker from
Digital Equipment. More details will appear in "Computing" nearer the date.
9. "MIXED FORTRAN AND PROLOG" - TALK BY DR DAVID BAILEY (SALFORD UNIVERSITY}
At the afternoon session Dr David Bailey from Salford University gave a talk
on "Mixed Fortran and Prolog", describing the implementation of the Salford Lisp/
Prolog System in Fortran 77. A synopsis appears in appendix E.
MIKE NUNN
Secretary
31 December 1984
Private circulation Document 84/54563
Technical Committee OIS/5 - Date: October 1984
Programming Languages
DRAFT BRITISH STANDARD METHOD FOR SPECIFYING REQUIREMENTS FOR FORTRAN LANGUAGE
PROCESSORS
FOREWORD
This British Standard has been prepared under the direction of the Office and
Information Systems Standards Committee. It is complementary to ANSI X3.9 -
1978 (= ISO 1539), the internationally recognized standard for the computer
programming language FORTRAN and needs to be read in conjunction with that
standard.
Compliance with a British Standard does not of itself confer immunity from legal
obligations.
CONTENTS Page
Foreword 1
Introduction 2
Specification
1. Scope 4
2. Definitions 5
3. Contents of the specification 6
4. Specification of requirements related to the requirements of
ANSI X3.9 - 1978 7
5. Specification of additional requirements not covered by
ANSI X3.9 - 1978 48
TABLE 1. Assignment statements 30
ZZ6277v 84/64563
Head Office 2 Park Street London W1A ZBS Tel O1-629 9000 Tx 266933 BSILON G
Information Services and Marketing Linford Wood Milton Keynes MK14 GLE Tel 0908 320033 Enquiries Tel 0908 320066 Tx 825777
Quality Assurance Division Maylands Avenue Heme] Hempstead Herts HP2 4SQ Tel 0442 3111 Tx 82424 BSIHHC G
Manchester Office 3 York Street Manchester M2 2AT Tel 061-832 3731 Tx 665969 BSIMAN G
Form 2-8305
To all Specialist
Groups Chairman
Date: 27th November 1984
Dear Chairman
Members Congress 29-31 March 1985
As you are aware the Society is organising a Member Congress at the University
of Reading to look at the image of the Society, its purpose and its future
development.
In order that the Specialist Groups obtain as much representation and exposure
as possible, groups are again asked to nominate a delegate to attend the Congress.
(Some groups have already nominated a delegate and may ignore this matter)
Enclosed is a copy of the proposed timetable and a form on which Specialist
Groups are asked to name their delegate, with 1st and 2nd choice. It would be
appreciated if all groups could return the forms, even if only to show a
'nil return'.
I would also like to confirm that fares to Reading and all accommodation and
conference fees will be paid by the Society.
Thanking you, in advance, for your cooperation.
Yours sincerely
Julia Allen
Liaison Executive Specialist Groups
EXC/92/84
THE BRITISH COMPUTER SOCIETY
13 MANSFIELD STREET, LONDON W1M 0BP
Members' Congress PROPOSED TIMETABLE
Friday 29th March 1985
3.00-7.00 pm Arrival at St Andrew's Hall, Reading.
7.15 pm Buffet dinner
8.30-9.30 pm Opening Session of Congress (in St Andrew's dining
Hall.) HOW THE OUTSIDER VIEWS THE SOCIETY
Alex d'Agapeyeff
Bar open to 10.30. Food available for late arrivals.
Saturday 30th March 1985
08.00 Breakfast at St Andrews
09.15-10.45 Plenary Session 1 in Lecture Theatre
THE CHARTERED SOCIETY;responsibilities;framework
and opportunities. John Ivinson & Derek Harding
10.45-11.15 Coffee
11.15-12.30 Plenary Session 2 - Introduction to the working
parties by the working party chairmen (4 x 15 mins)
12.30-14.00 LUNCH
14.00-15.30 1st working party Session
16.00-17.30 2nd working party Session
17.30-19.00 Free time/special sessions/ overrun etc
19.30 for 20.00 (Formal) reception & dinner.
Guest speaker: John Ashworth or Philip Hughes
Sunday 31st March 1985
08.30 Breakfast
09.30-10.45 Final working party session
10.45-11.15 Coffee
11.15-12.30 Plenary Session 3 - reports of the working parties
13.00-14.30 LUNCH
14.30-15.30 Plenary Session 4 - summing up and rallying
(Bob McLaughlin)
15.30 Tea and dispersal
WORKING PARTY THEMES AND TOPICS
1. Outward:
Image and Role of Society
Social responsibilities
Next 5 years - leading edge
Technical developments
End-user activity
2. Inward:
Structure
Growth/recruitment
Services to members:
publications
events
other services
Finance
3. Professional:
Professional Development Scheme
Courses - internal for BCS exams
external
Exemptions and validations
Professional standards and Codes of Practice
Registration and licensing
4. Miscellaneous:
Junior membership and schools relations
Micro-groups
Relationship with other bodies.
------------------------------
The following names were put forward as desirable working party
chairmen:
Outward: Adrian Norman or
Gerry Fisher
Inward: Chris Hudson or
Dick Paine
Professional: Ernest Morris or
Dennis Blackwell
Miscellaneous: Jim Nix or
David Menzies
To: NAG,BCS,DAP, etc.
From: John Reid
Date: 20 November 1984
Subject: Report on X3J3 meeting at Fort Lauderdale,
12-16 November 1984
References:
[1] 92(*)WSB-4 Delete WHILE control from the block DO
[2] 92(*)JTM-2 WHILE control considered harmful
[3] 92(.)RPJW-l Reconsidering WHILE
[4] 92.RLP-l Signal processing module
[5] 92(7)KWH-l Exception handling in hierarchically designed programs
[6] 92(7)KWH-2 CONDITION and ENABLE
[7] 92(7)KWH-3 Intrinsic conditions proposal
[8] 92(11)JLW/JKR-l Source form
[9] 90(*)JTM-l Proposed intra-language compatibility policy
[10] 92(9)JLS-l Extended declarations
[1l] 92(*)GEM-l Bit data type proposals
[12] 92.JLW-3 Bit data type module
[13] 92(9)KWH-4 Proposals on variably associated names
[14] 92(6)JKR-l Many-one maps in IDENTITY
[15] 92(6)JKR-2 Replacement of vector-valued sections
[16] 92(11)JKR-3 RECL lengths
[17] 92(*)JTM-l Construct names - where to put them
[18] 92(9/6)JLS-2 Qualification of structure arrays
l. Summary
This was an active meeting which was agreed to be the last for
technical proposals other than those needed to rectify flaws in the
language during document preparation. Proposals were therefore pushed
through to formal votes in circumstances that would normally have led
to fresh proposals being prepared for the next meeting. The following
were passed
(l) deletion of WHILE,
(2) exception handling,
(3) deletion of event handling,
(4) multi-statement lines and in-line commentary in the old source form,
(5) extensions to type statements,
(6) BIT data type,
(7) INQUIRY for RECL length of an io-list,
(8) mathematical notation for comparisons (e.g. < for .LT.),
(9) use as arrays of arrays of structure components.
It was followed by a working weekend to consider the language
document S8. The committee has become serious about the writing of S8
as its top priority from now on. No more versions of S7 will be
produced and it will be left to section authors to incorporate
technical proposals passed at this meeting into S8.
2. DO WHILE
Three papers ([1],[2],[3]) opposed the DO WHILE on the grounds
that it adds no functionality, that there was negative reaction at the
Fort Collins forum, and that beginners are misled about when the test
is made, whereas exit is just what is needed. It was passed at
Jackson only narrowly (12-l0) and at this meeting was deleted (18-8)
on a roll-call vote.
3. Application module for signal processing
The proposal [4] to standardize an application module for signal
processing (Fourier transforms, etc) was not favoured (6-ll-14).
There was concern that few members of the committee have the
competence to judge the merits of such a module, though they have the
competence to judge the interface (the part that would be
standardized); there was confusion as to whether X3J3 is the right
body to standardize such a module, what procedures would be necessary
to do so and what its status would be.
4. Exception handling
Kurt Hirchert's proposals on exception handling (see [5]),
essentially unchanged since 6 months ago, were reconsidered. The main
proposal [6] passed (20-5) and the proposal specifying conditions [7]
passed (21-l). A straw vote (10-3-16) favoured handling STOP
similarly. A proposal to delete the event handling features passed
(24-0). A straw vote on "can X3J3 accept the goal of integrating at
least a minimum set of features for multitasking and synchronization
in Fortran 8x?" was negative (6-22-2).
5. Source form and significant blanks
The committee spent a long time discussing the source form and
significant blanks but the only change made was to add in-line
commentary and multi-statement lines to the old source form (16-5).
Last meeting's proposal to delete significant blanks was put afresh
and failed (12-12). The idea of having a single source form was
favoured (28-2-6) and Jerry Wagener and I suggested two ways to
achieve this:
(1) (see [8]) add to the old source form the compatible parts
of the new form; deprecate insignificant blanks, and
(2) standardize on the new form only but provide a preprocessor
to convert old programs to the new form.
A straw vote favoured the second approach (5-25-4). It was pointed
out that other minor transformations could be handled (e.g. ".LE."
might be replaced by "<") and such an approach was in line with the
intralanguage (i.e. between versions) compatibility guide-lines [9]
but worries were expressed about whether the preprocessor could be
written without errors and the possibility of the committee being sued
for the consequences of errors. Straw votes on this proposal failed
(5-27-2 and 6-23-2). The original proposal was then reconsidered and
received a favourable straw vote (19-7-6) but eventually failed (7-15)
despite the realization that old standard says nothing about columns
73 onwards so one of the objections, the barrier at column 73, was not
real. Confusion over this matter may have led to the negative vote.
Jerry Wagener's wish for implicit continuation following any line
ending "," and a variety of other possibilities, failed (6-14-12,
9-17-4, 8-18-4).
6. Extended type statement
Lawrie Schonfelder[10] proposed extensions to the type statement
to allow all the properties of a data object to be declared in one
statement, which was the main purpose of entity-oriented declarations
(deleted at the last meeting). A simple example of the new form is
REAL,SAVE,ARRAY(lO,lO)::A,B,C(2O)
Straw votes favoured PARAMETER as opposed to CONSTANT for constants
(14-7-l0), for default ARRAY properties to be included in the
attribute list (e.g. in the above example A and B have shape [10,10]
but C has shape [2O]) (18-8-9), and for the keyword ARRAY rather than
DIMENSION (19-8-8). The proposal passed (22-5). A new INITIALIZE
statement, exemplified by
INITIALIZE(A(6:l0)=[7,8,3,4,6])
gives the functionality of DATA for initializing parts of arrays.
7. BIT data type
Geoff Millard proposed a BIT data type [11] consisting of a
single bit and relying on a small number of intrinsics and on the
array features of the language to do worthwhile operations. This was
favoured (25-8-5) over the S6 approach of strings of bits (similar to
character data). It was also favoured (22-11-4) over Jerry Wagener's
proposal [12] for derived data type in a module, although the latter
would have given very similar capabilities and have had a very
insignificant effect on the language, confining the description to a
single section; the committee was concerned about the likelihood of
inefficient implementation and about i/o, which is still not resolved
for derived data types. The proposal passed (14-9).
8. Pointers
Kurt Hirchert gave a presentation of his ideas [13] on "variably
associated names" and received a favourable straw vote (13-10-9) but
did not have a formal proposal ready.
9. Language document preparation
The chairman became very concerned about the technical changes
being passed at a meeting that was intended to give priority to
preparation of the document, and asked the subcommittees to consider
the possibility of standardizing the array features as an extension of
Fortran 77. However no one was keen on the idea, although the array
subgroup reported that there were no technical difficulties. It was
thought that this would not save very much time for the array
features, while it would lose a great deal of time for the rest of the
language. It would also threaten the continuity of the work since
only the array subgroup would remain active. The idea was dismissed
and a ban on technical proposals while S8 is constructed and honed
into shape was accepted.
It is anticipated that it may be two years before a draft is
available for public comment and a further two years before the
language is formally accepted.
Those active in the preparation of the document remained for the
weekend after the meeting to work on it.
l0. Array features
Ten different ways to express the IDENTIFY syntax were
considered. The preferred variants are exemplified by
(l) IDENTIFY(F(I)=B(8-I,I), I=l:5)
(2) IDENTIFY(F(I=l:5)=B(8-I,I))
and in a run-off (l) was slightly more popular (15-12-6).
My two personal proposals on banning many-one maps in IDENTIFY
statements [14] and replacing vector-valued array sections by
intrinsics [15] failed (5-16,4-19), although in both cases initial
straw votes were favourable (17-8-7,13-9-12). It is disappointing
that so few supported my view of the importance of safety and
regularity as opposed to notational convenience.
Examples for the function PROJECT were accepted (26-0).
ll. Input-output
My proposal [16] on an inquiry statement to find out the lengths
(in processor-dependent units) of an unformatted io-list passed (11-l0).
The keyword RECL was replaced by IOLENGTH so that the statement takes the form
INQUIRE(IOLENGTH-iolen)iolist
where iolen is an integer variable. I agreed in sub-group that my
first proposal for this purpose in [16] was inadequate and that my
proposal [17] on avoiding automatic line feeds did not meet all the
requirements for input-output to terminals (principally because I did
not address the practice of using separate units for input and output
to a terminal).
12. Relational operators
The use of the notation < for .LT., <= for .LE., == for .EQ., <>
for .NE., > for .GT., and >= for .GE. was reconsidered following the
decision at the last meeting not to use <,> for "angle brackets".
This time the proposal passed (16-9).
13. Return of function results
Walt Brainerd suggested that the FUNCTION statement could be
simplified by allowing the result to be attached to the return
statement. He did not have a formal proposal but the committee
encouraged him to work on it (l0-4-13).
14. Construct names
Jeanne Martin [17] wanted construct names to appear on the right
rather than the left of initial statements of blocks, but did not
convince the committee (8-13).
15. Qualification of structure arrays
Lawrie Schonfelder has wished for a long time to be able to use
arrays of structure components as arrays in array expressions and as
actual arguments, but met much opposition. However on this occasion
his proposal 2 [18] passed (2l-l). This keeps the present form (e.g.
STRUCTURE%COMPONENT) and was preferred (25-4-1) to proposal 1, in which
the component names are written ahead of the structure names so that
COMPONENT(I,J)%STRUCTURE(K,L)
corresponds to
ARRAY(I,J,K,L)
if ARRAY=COMPONENT%STRUCTURE.
16. Next meeting
The next meeting will be held in the week 11-15 February. The
deadline for pre-meeting distribution (receipt of material in US) is
January 10th.
The Group would welcome suggestions from members for topics etc for future
meetings. So could anyone with ideas complete the attached form and send it
to the Secretary.
SUBJECT(S) SPEAKER
Please list anyone (if known)
who you would suggest to talk
on each suggested subject.
[address and phone no. would help]
ORIGINATING MEMBER'S NAME, ADDRESS, PHONE NO
Please send this to:
Mike Nunn
Secretary
BCS Fortran Specialist Group
CCTA
Room 408
Riverwalk House
London
SW1P 4RT
"MIXED FORTRAN AND PROLOG" - TALK BY DR DAVID BAILEY (SALFORD UNIVERSITY)
ORIGINS
Salford University developed a Fortran 77 compiler for the ICL 1900 in 1978. At
a later date they implemented it on their PRIME system and went on to sell it
successfully worldwide in competition with PRIME's own compiler.
BACKGROUND TO PROLOG
Prolog was so named as an abbreviation for "Programming in Logic". It first
appeared in 1972 as the result of work on computers in the 1960s associated with
theorem proving using first order predicate calculus.
NATURE OF PROLOG
Rules and facts are the only constituents of Prolog programs.
Examples
(i) a Prolog fact:
parent (joe, olga)
(ii) in Prolog you can ask questions in which one of the components
is a variable (and will thus acquire a value):
father (reginald, david)
(iii) sets of Prolog rules:
brothers (x,y):- parent (z,x) parent (z-y)
male (x), male (y,x)=y)
mother:- parent (x,y) female (x)
(iv) whereas in Fortran one can have assignment statements
EG x=y, y=y+1
these have no equivalent in Prolog where a variable takes
one of two states viz: uninstantiated (undefined)
or instantiated
(v) lists:
[a,b,c]
a list of any 3 objects which might acquire
values later
[a,b/x]
a list of any length in which the first two
elements are a and b
RECOMMENDED BOOK ON PROLOG
To learn Prolog David Bailey recommends the book "Programming in Prolog" by
Clocksin and Mellish.
THE SALFORD PROLOG IMPLEMENTATION
The Salford Prolog implementation is written in Fortran 77. One of the essentials
is a flexible mechanism for holding structures. Store is broken up into a large
number of cells used as absolute addresses. Lists of variables are kept in "trails"
with addresses for backtracking and places to jump out to at choice points.
Matrix manipulation and iterative processes are not suitable for Prolog
because they need fast execution speed and easy coding. But engineering packages
seem well Suited to having front-ends written in Prolog.
The Salford implementation costs £2000 to academic users. There are no plans
to port it onto other machines at present.
THE BRITISH COMPUTER SOCIETY
13 Mansfield Street, London WlM 0BP
Formation of a Specialist Group for the understanding and promotion of
Computation as Physics.
Much research is being reported from the USA in this area which appears
of fundamental importance and highly relevant to the achievement of 5th
Generation Objectives. Its specific remit concerns the physics or thermo
-dynamics of computational processes and their reversibility as understood
via algorithmic information theory and about how computational structures
reproduce and evolve via the theory of cellular automata - the second half
of the computational inheritance that Von Neumann left us. It concerns
Ballistic, Brownian, Boltzman and Cellular Automata architectures.
The purpose is to provide a focus and a nucleus around which those with an
interest in these fields could crystallize their activities and make
contacts.
Would all those with an interest or potential interest in such a group
please contact:
Peter Marcer FBCS
65 Wellsway
Keynsham
Avon BS18 1HX
Tel: 0272 86 4729
It is hoped to constitute the first meeting of the Group at the beginning
of the new year.