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).


6.2 Completeness Module


        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".



APPENDIX A


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.




APPENDIX B


  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