British Computer Society - Fortran Specialist Group
Minutes of the Annual General Meeting held at BCS Headquarters
on Monday, 31st March 1980
Present: G.L. Harding (Chairman) ECMWF
P.A. Clarke Rothamsted Experimental Stn
M.R. Dolbear B.P. London
E.W. Gorczynski B.P. Research Centre
P. Kraven British National Oil Corpn
J.D. Murchland
K. Normington Coventry Polytechnic
M. Nunn CCTA
G.A. Ruscoe GEISCO
J. Thomas GEISCO
T.L. van Raalte MOD
A. Wilson ICL
J. D. Wilson (Secretary) Leicester University
1. Minutes of Previous Meeting [4 February 1980]
The minutes were approved.
2. Matters arising
The dates of the ISO Fortran Experts meeting in Amsterdam
have been changed to October 20-23, 1980. It has been suggested
that the BCS Fortran Specialist Group hold a Fortran Forum, along
the same lines as the 1978 meeting, in the UK on Friday, 24th
October. Several members of ANSI X3J3 would be willing to par-
ticipate. The Chairman is to get in touch with X3J3 to discuss
the suggestion.
3. Election of Officers for the Session 1980/81
The following officers were elected by those present at
the meeting:
Chairman: G.L. Harding - proposed: G.A. Ruscoe; seconded J.D. Wilson
Vice-Chairman: A. Clarke - proposed: P. Kraven; seconded G.A. Ruscoe
Secretary: J.D. Wilson - proposed: A. Clarke; seconded G. Harding
Treasurer: no formal vote was taken but it was agreed that
J. Roberts-Jones should be asked to continue in this function.
(He has since accepted.)
Steering Committee Members: J. Murchland
D. Muxworthy
J. Roberts-Jones
G.A. Ruscoe (new member)
T.L. van Raalte (new member)
A. Wilson
The mailing list currently consists of 101 UK members
plus 33 overseas members. The Secretary was asked to circulate
a questionnaire dealing with the activities of the Group to all
members.
4. Treasurer's Report
The Report for the session 1979/80 was not presented at the
meeting due to the absence of the Treasurer. A copy of the Report
will be circulated to members when available. The Chairman noted
that the Group, in common with the other Specialist Groups, has
been asked to transfer its bank account to Lloyds at Langham Place,
London.
It was decided that the annual membership fee of the Group
to non-BCS members be raised to £2.
5. Future Activities
The Secretary reported that presentations have been tenta-
tively arranged by the following:
Dr. Brian Smith, Argonne National Laboratory, USA.
Dr. J. Larmouth, Salford University - portability with Fortran 77
Dr. K. Roberts, Culham Lab. - the Olympus system.
In addition, the following subjects were suggested if suitable
speakers could be found: Fortran on Micros; experience with
Fortran 77 compilers; Fortran teaching aids.
Other suggestions and/or offers from members would be welcome
and should be made to any member of the Steering Committee.
6. X3J3 Activities
6.1 Report from latest meetings
A. Wilson reported on the 2 most recent X3J3 meetings. A
discussion paper on a proposed Completeness Module (see below)
was submitted by BSI/DPS13/WG6 but was referred to the May meeting
due to lack of time. ANSI have issued a press release on signifi-
cant blanks in the next standard (they have currently voted in
favour of this).
M. Dolbear said that blanks could be used to produce more
readable programs: however he suggested that any proposal would
be acceptable provided it is possible to write an automatic con-
verter to the new standard feature. A. Clarke and J. Wilson felt
there would still be a large overhead involved in the recompilation
of existing suites of programs. A straw vote on significant blanks,
or rather abandoning insignificant blanks, resulted in:
for: 6 against: 2 Abstentions: 3
A majority was also in favour of requiring any new proposal to have
a mechanism for auto-conversion.
X3J3 are considering the possibility of introducing a compile-
time CALL mechanism to allow communication with a non-Fortran
object, such as a Codasyl Schema in a Data Base. The idea is rather
vague at present. G. Ruscoe said this seems similar to an INVOKE
or INCLUDE feature. Macro facilities are also being considered.
There was some debate as to whether this should be a part of the
Fortran language specifications.
Other topics included character extensions, null strings and
sub-strings and concatenation.
The revised timetable now sets 1985 as the date for final
agreement although in 1983 ANSI will be required to decide what
to do with the current standard (5-year review requirement).
A. Clarke presented the BSI proposal contained in Appendix A.
The aim is to define actions for those situations at present
ignored by the Standard and thereby make Fortran a "safer" langu-
age to use.
A. Wilson thought all a compiler could do would be to say
whether something was non-standard.
A. Clarke said he hoped that if such a module were accepted
it could be included as part of the language in future standards.
M. Dolbear said the U.S. Government may do the job for us by
requiring that compile-time errors be explicitly defined.
It was agreed that the proposal should be only for the Core
at this stage. It was also accepted that it is not possible to
do the full job at present; some features which may be considered
too expensive to implement could be left out.
A. Clarke felt that X3J3 had been too concerned with speed
and efficiency rather than "safety". Many users would be prepared
to forgo some "speed" for increased "safety" now that modern
processors are adequately fast. The proposal would not solve the
problem of incorrect programs but would greatly enhance user's
ability to ensure that their programs were standard conforming,
portable and safe.
J. Wilson expressed the view that this is what X3J3 really
should be doing instead of making minor syntactic changes.
7. Activities of other Fortran Groups
A brief report has been received from the Dutch Fortran
Specialist Group. Several members have also received copies of
the U.S. Department of Energy Report entitled Fortran Language
Requirements. It adopts a nested approach rather than core-plus
modules. (A copy may be borrowed from the Secretary.)
8. B.C.S. Business
Representation on ANSI X3J3. The BCS has expressed interest
in the idea but has no money available. An approach is being made
to the Department of Industry. Further justification is to be
written out and presented by the Chairman.
Nominations for Honorary Fellows of the BCS are requested.
9. Next Meeting
The next meeting will take place on Tuesday, 27th May 1980
at the BCS Headquarters. The afternoon session will be devoted
to a talk and discussion on Numerical Precision and Environmental
Enquiry by Dr. Brian Smith, Argonne Laboratory, USA.
10. Afternoon session
Alan Clarke of Rothamsted Experimental Station gave a talk
entitled "Array Processing in GENSTAT".
M E M O R A N D U M
From: BSI DPSl3 WG6 To: ANSI X3J3
Date: 26th February, 1980
Subject: COMPLETENESS OR CLOSURE MODULE(S)
Objectives
For some time, members of the BCS Fortran Specialist Group have been
expressing the desire that the Fortran Standard should be more rigorous
and enforceable. Some reasons put forward for this include:
(1) The lack of a standard that can be adopted or enforced by simple
constraints leads many users to unknowingly abandon standards.
Adoption or enforcement by study of the standards document is not
seen as an effective way of achieving the aims of the standard
(e.g. portability etc.). Too many users rely on their processor
to define for them what they can and can not do in "Fortran".
(2) Users lose confidence in a language that apparently "varies" from
processor to processor but is claimed to be "standard". To such
a user it appears that the standard is useless.
(3) ANSI does not give a "stamp of approval" to any compiling systems
and the purchaser could spend considerable time determining if
the product he is buying is indeed standard-conforming.
(4) There is a notion of "safety" and "performance" related to most
standard products. As the existing Fortran standard is drafted, both
these notions could be missing from a compiler but it could still be
"standard conforming".
(5) The standard document should be unambiguous on all points so that it
could be used as a document for legal purposes - this means that "loop
holes" when discovered should be corrected as soon as possible, and
preferably shouldn't exist in the first place.
These requirements are in conflict with the requirement for extensibility an
open-endedness which are important for the natural growth of the language -
and it is because of this that previous proposals for a more rigorous,
"complete" language have been disregarded.
This proposal has the same objectives but a different approach that
relies on the new possibility of providing for these requirements in an
optional module (as part of the core plus modules approach).
The proposal
The proposal is that a standardised completeness (or closure) module
be specified for Fortran.
This is an optional module that defines what the Fortran Processor
should do in all circumstances. This means that actions need to be defined
for all syntax errors and run-time errors. (The word error is used here to
mean undefined status conditions, or something similar). Thus "Complete
Fortran" is a permitted optional extension of "Fortran".
Example 1
(Minimal) Fortran Complete Fortran
-------- --------
| CORE | | CORE |
-------- --------
|
--------------
| COMPLETENESS |
| MODULE |
--------------
Notes:
1. That when the completeness module is requested, this excludes certain
statements e.g. manufacturers extensions.
2. The completeness module may not be extended by a manufacturer (or anyone
else, other than ANSI X3J3).
3. In the following description I assume that the completeness module will
consist of the minimum processing consistent with creating a "complete"
language and having a minimum overhead on processing.
4. The proposal adds no new syntax to the language.
Draft details of the content of the COMPLETENESS or CLOSURE Module
This is an initial suggestion to illustrate the approach. Fuller descriptions
could be prepared if desired.
(1) Syntax processing with the completeness module
Any statement in a user program which does not conform to those defined
in the Standard Fortran Language (say CORE for now) will cause the
processor to output the following text (to the "default unit" or to
the listing device)
SYNTAX ERROR <message>
where <message> is a character string that helps the user understand
why the processor has taken this action.
(2) Run-time processing with the completeness module
Any statement in a user program which does not have a defined
interpretation in the Standard Fortran Language (say CORE for now) will
cause the processor to output the following text (to the default unit)
PROCESSING ERROR <message>
where <message> is a character string that helps the user understand
why the processor has taken this action.
The processor then STOP's.
Notes
1) The actual <message> strings for various situations could be defined
by the committee and would probably be similar to those proposed for
BASIC. standard error messages would be a great help to users. Currently
they are needlessly varying in quality.
2) This proposal meets all the objectives listed. "Performance" standards
should be just-as good as Fortran 77 - where most of these features are
defined by manufacturers extensions.
There is quite an improvement in safety.
3) We feel that many users are happier with a restrictive processor with a
few simple rules to obey, than an open-ended unpredictable processor.
Some Problems with this Proposal
Multi-module programs
Up to now, it has been assumed that Fortran consists of a single module
(i.e. the CORE). How could the idea of a processor "completeness module"
operate when the user requires access to several modules? One possibility is
that:
Each module has a "completeness module" associated with it
Example 2
Database Fortran Complete Database Fortran
-------- -------- --------------
| CORE | | CORE |-------| Partial CORE |
-------- -------- | COMPLETENESS |
| | | MODULE |
| | --------------
---------- ---------- --------------
| Database | | Database | | database |
| Module | | Module |-------| completeness |
---------- ---------- | module |
--------------
The above example is intended to convey the idea that CORE Fortran
has been extended to include:
(a) a database module that defines what happens to "database language
statements" and
(b) a (Partial) core completeness module that defines what happens to
all statements other than core and database ones. This is called
"partial" because it has to allow for database statements whereas in
Example 1 the core completeness module did not permit database
statements.
Because it is possible that database statements have not been completely
defined, a database completeness module defines what happens when a non-standard
database statement is processed. In practice there does exist differences between
the database statements provided by various manufacturers and the CODASYL Fortran
proposals, so the database completeness module would be useful for pinpointing
the incompatibilities.
The difficulty can be summarised by saying that a combination of
completeness modules are required with each combination of core plus modules that
the user selects. A way is needed to overcome this "combination" effect.
Implementation of completeness Module
X3J3 have not addressed the problem of how modules are to be implemented.
However, in this case, very many processors already provide much of the
"Completeness Module" as manufacturer extensions.
In this category would be:
l. The majority of syntax error messages
2. Most run-time errors (e.g. division by zero, array bounds, addressing
error, operation code trap etc.).
The most difficult areas for implementation are things like:
3. sizes of programs, .length of arrays, functions with side effects etc.
4. Precision of numbers and errors in standard functions caused by this.
hopefully X3J3 will have defined actions for many of these for the next standard.
A compiler option could be used to access the completeness module.
Revision of Completeness Module during Fortran revisions
Because all actions taken by the completeness module result in output that
is of value only during program "development" (i.e. error messages, premature
program termination, etc.) and would not normally be produced by "production"
programs, there would be no user investment in completeness module functions.
Because of this, it is possible to change the Completeness Module with
minimum or no effect on users existing "production" programs.
It is anticipated that it will always be necessary to revise the completeness
module when Fortran is revised.
Responsibility for the Completeness Module
The completeness module is more of a "language" feature than an "application"
feature, and should be maintained and developed by ANSI X3J3 as part of the general
purpose language standard.
Conclusions
Completeness Module would make a significant improvement in portability,
without toil, for those who wish for it.
Optional enforcement of standards by mechanical means seems to be the only
realistic way of making standards "work". The existing situation relies on the
somewhat theoretical premise that users will study and understand the standard -
in practice 95% don't - but they could become much more aware at the "flick of
a switch".
Largely this proposal consists of standardising manufacturers extensions
and hence can make use of proven features and does not involve design of novel
features.
Suggested Straw votes on the proposed Completeness Module
1. X3J3 should take a major role in establishing and
maintaining the "safety" aspects of Fortran. This
should not be left to individual manufacturers,
compiler producers etc..
2. Users would benefit significantly from optionally
being able to rely on their Fortran processor to
define for them what they can and cannot do in standard
Fortran (through constraints such as error messages etc.)
3. For the set of all possible inputs to the Fortran
processor, there should be a complete set of standard
outputs some of which are mandatory and some of which
are optional.
If there is a majority in favour of 1,2 or 3
4. The proposed optional standard Completeness Module
is a good way of meeting the above requirements and
should be developed further.
SUMMARY OF TALK ON ARRAY PROCESSING IN GENSTAT by P.A.CLARKE
l. GENERAL
Whereas Fortran is a single element calculus, GENSTAT is a structure calculus.
The term "vector" is used to apply to structures with ordered sets of elements
which include variate integer factor, names and other structures are: matrix,
symmat (symmetric matrix), diagmat (diagonal matrix), Table (multiway contingency
tables) and DSSP (a sums of squares and products structure). The talk covered
a subset of GENSTAT facilities relating to current Fortran array processing
proposals.
2. LISTS
Generalised "lists" are useful for (a) set of values, (b) a set of instructions
or (c) a set of structures and provide many of the features for which Fortran
loop control structures would be required for example:
(a) list of values Example Meaning
Repeating factor 1...5 1,2,3,4,5
1,3...N 1,3,5,7,---Value N
1.2,2.4,...14.4 1.2,2.4,3.6,...value 14.4
P,Q...R Step from P up to R in steps of (Q-P)
Premultiplier 3(1,2) 1,1,1, 2,2,2
J!(K,3) J lots of K followed by J lots of 3
A!(B!(C!(1))) AxBxC ones
Postmultiplier (1,2)3 1,2,1,2,1,2
(A,B)J J lots of (A followed by B)
Combined 3(1,2)3 1,1,1,2,2,2,1,1,1,2,2,2,1,1,1,2,2,2
N!(3(1,3...11)J)2 is allowed (nesting to depth 20)
(b) list of vectors V(1...5) Five vectors named V(1),V(2),V(3)
V(4),V(5)
(c) list of instructions A,B,C=(B,C,D)+1 A=B+1
B=C+1
C=D+1
DECLARATIONS
A typical "variate" named V of length 6 vector would be declared and given
initial values by:
'VARIATE' V$6 = 1,3...11 for example.
A typical "factors" vector named F of length 6 and with 2 levels and given
initial values would be declared by:
'FACTOR' F$2,6 = 1,2,2,1,1,1 for example.
Factor values may only take a finite number of discrete value levels,
e.g. the value 1 or the value 2 in the above case.
Note the 'DEVALUE' command deletes structures and deallocates storage for
possible re-use.
CALCULATION ('CALC' command)
Eg.l 'CALC' A=6.3 sets all elements of A to 6.3
Eg.2 'CALC' A=B+C where A,B and C must be of the same type
The operator acts as a scalar or operation depending on the types of A,B
and C. A result will occur for all sensible combinations of types of A,B and C.
'CALC' X(1...6)=Y(1...6)*Z(1...6)
acts on each of the set of vectors i.e. as if
'CALC' X(1) = Y(1)*Z(1)
'CALC' X(2) = Y(2)*Z(2)
etc.
Note that all operators act on an element-by-element basis thus for MATRIX
vectors A,B and C,
'CALC' A=B*C Multiplies the first element of B by the first element of C
and puts the result in the first element of A, etc.
Whereas 'CALC' A=PDT(B;C) forms a matrix product in A.
FUNCTIONS
S = SUM(V) forms sum of all elements of a vector
V = VSUM(V(...5)) does the same as V(1)+V(2)+V(3)+V(4)+V(5), but takes
"missing-values"into account.
v = VARFAC(F) converts a FACTOR vector into a VARIATE vector.
S = NVAL(V) returns the number of elements in a vector.
V = ORDER(V) sorts the vector's values into ascending order.
F = INTPT(V) converts from VARIATE vector to FACTOR vector
TRANSFERRING VALUES BETWEEN TYPES ('EQUATE' command)
To give 20 scalars called S(1),S(2),...S(20) the values corresponding to
the first, second...twentieth elements of a VARIATE vector V the following could
be used:
declarations 'SCALAR' S(1...20)
'VARIATE' V$2O
transfer 'EQUATE' S(1...2O) = V
This can enable parts of structures to be accessed. Also 'COPY' instruction and
ELEM function can do this in a more dynamic way.
INPUT/OUTPUT values may be transput in parallel or in series.
For example for variates A and B declared as
'VARIATE' A$4 = 1,2,3,4
'VARIATE' B$4 = 6,7,8,9
'PRINT' A B whereas 'PRINT/P' A B
outputs outputs
A A B
1 1 6
2 2 7
3 3 8
4 4 9
B
1
2
3
4
EXAMPLE
An example of a Land Capability Mapping exercise which used GENSTAT
(Originating from the Statistics Dept., Rothamsted) and SYMAP (from the
Laboratory for Spacial Graphics, Harvard) was described.
PAC
6 May 80