BRITISH COMPUTER SOCIETY - FORTRAN SPECIALIST GROUP
MINUTES OF MEETING HELD AT BCS HQ, MANSFIELD STREET, LONDON
ON 11 MARCH 1985 (included AGM)
Present: R T Bowles - BP Oil
S Brazier - Prime Computer
Eric Davison - DEC
J L Dyke - H.R.C.
I D Hill - MRC
Chris Lazou - ULCC
K Norminqton - Coventry Polytechnic
Mike Nunn - CCTA
John Reid - Harwell
E G Reilly - BSRA
D M Vallance - Salford University
S Watkins - UMIST
Addresses:
Chairman John Wilson
Computer Laboratory
University of Leicester
LEICESTER
LE1 7RH
Telephone: 0533 554455
Vice-chairman Keith Normington
Computer Centre
Coventry (Lanchester) Polytechnic
COVENTRY
CV1 5PB
Secretary Mike Nunn
CCTA
Riverwalk House
157 Millbank
LONDON
SW1P 4RT
Treasurer John Dyke
Huntingdon Research Centre
HUNTINGDON
PE13 6ES
l. APOLOGIES FOR ABSENCE
Apologies were received from Lawrie Schonfelder (Liverpool University),
David Maxworthy (Edinburgh University) and John Wilson (Leicester University).
John had unfortunately been recently involved in a car accident in which he
suffered broken ribs. [Happily he has since made a good recovery].
In his absence our Vice-chairman Keith Normington took the chair at the
meeting.
2. MINUTES OF LAST MEETING [10 December 1984]
The minutes were accepted without amendment.
3. MATTERS ARISING
(i) Draft BSI standard document "Method of Specifying Requirements
for FORTRAN Language Processors".
David Hill (BSI committee member) reported that BSI had now
sent the standard document out for public comment. It will
probably be advertised in Computer Weekly. Comments received
will be considered by the Working Party.
(ii) There was some discussion on whether it would be useful to
send copies of the Group's newsletters to prominent computing
newspapers to gain publicity for our activities. It was agreed
to do so subject to further review, although inclusion of
reports on the afternoon talks would have to be subject to
special agreement.
(iii) ISO/TC97/SC22/WG5 meeting in Bonn, July l-5 1985
A letter had been received from David Maxworthy (see Appendix A)
drawing attention to the fact that those intending to attend as
UK delegates needed to be formally approved by BSI. Anyone
wanting to go should ring David at the Program Unit, Edinburgh
University - telephone 031-667 1011 ext 6756.
(iv) Dates were agreed for future Fortran Special Group meetings
as follows:
Monday June 10th 1985
Monday September 16th 1985
Monday December 9th 1985
Monday March 17th 1986
4. BCS BUSINESS
(i) After discussion it was agreed that the Group's annual fee
for non-BCS members would remain at £5. Outstanding subscriptions
should be sent to our Treasurer at the address on the front page
of these minutes.
(ii) There was some debate on potential subjects for talks at the
afternoon session of future meetings. (An earlier newsletter
invited suggestions but nothing was received). Topics suggested
were:
Toolpack - someone from NAG
Fortran on micros - some sort of general discussion
Certification of compilers via the NCC validation scheme
Particular areas of '8X' - John Reid
Draft BSI Standard (Method of Specifying Requirements for Fortran
Language Processors)- Brian Meek
(i) The latest X3J3 meeting had taken place at Monterey in February.
John Reid reported that the emphasis had been to include no fresh
technical problems (although some new intrinsic functions leaked in)
Subjects which generated particular discussion included:
What a variable means - in '8X' a variable is any entity whose
value can vary
Array functions
Treating double precision as a special form of reals
Expected timescales:
'8X' undergoes public comment period - 1986
'8X' published as new standard - 1988
John Reid has provided a detailed report on the Monterey meeting
which appears in appendix B.
(ii) A report from the Bonn ISO meeting will be on the agenda of the
coming X3J3 meeting at Oxford in July.
6. FORTRAN FORUM 1985
The BCS FORTRAN Specialist Group is holding a "FORTRAN FORUM 1985" at the
Institute of Education, London on 15th July. This will immediately follow
the first X3J3 meeting outside North America. At "FORTRAN FORUM" leading
members of X3J3 will present the contents of the forthcoming standard '8X'.
Talks will be as follows:
Introduction - John Reid
Development of FORTRAN 8X - Jeanne Adams
Overview of FORTRAN 8X - Walt Brainerd
Array features - Alan Wilson
Data abstraction - Jerry Wagener
I/O extensions - Jim Matheny
Deprecated features - Lawrie Schonfelder
A fuller description of "FORTRAN FORUM 85" and booking form to attend is
enclosed as a brochure with these minutes. To help with lunch reservations
please make your bookings as soon as possible.
Those wishing to attend the 8-12 JUlY X3J3 meeting at Oxford preceding "FORTRAN
FORUM" should complete the booking form in appendix E and send it to John Reid
by 14th June.
7. AGM
(i) The following officers were re-elected:
Chairman - John Wilson (Leicester University)
Vice-chairman - Keith Normington (Coventry Polytechnic)
Secretary - Mike Nunn (CCTA)
J L Dyke was elected as Treasurer. The Group expresses its
thanks to Keith Normington for manfully taking over the
Treasurer's duties at short notice for most of last year as
well as functioning as vice-chairman.
(ii) The Treasurer reported that we overspent our allocated budget
last year, mainly because BCS HQ costs charged to us have increased.
This year we seek an allocation of £800. A detailed statement
of the Group's accounts will appear with the next newsletter.
8. DATE OF NEXT MEETING
The next meeting of the Group will be held on Monday June 10th 1985 from
10.45 am to 4 pm at BCS Headquarters. In the afternoon Brian Meek
of the BSI Committee will give a talk on the BSI Standard "Method for
Specifying Requirements for FORTRAN Language Processors".
9. DEC FORTRAN COMPILERS AND PROGRAM DEVELOPMENT AIDS
At the afternoon session Eric Davison gave a talk on DEC's FORTRAN
compilers and program development aids. A summary of this appears in
MIKE NUNN
(Secretary)
2 May 1985
Program Library Unit University of Edinburgh Director: Dr. G.M. Stacey
18 Buccleuch Place Edinburgh EH8 9LN Telephone 031 667 1011 ext 6756 Telex 727442 (Attention: PLU)
19th February 1985
Dear Colleague,
ISO/TC97/SC22/WG5 MEETING IN BONN, JULY 1 - 5 1985
You will probably have already received a notice from Jeanne Martin, the
convener, about the above meeting. May I remind you that UK delegates
should formally be approved by BSI ? It would therefore be helpful if
you would let me know by March 11 at the latest if you intend to be at
the Bonn meeting, so that I can present a list of names at the BSI
Programming Languages committee meeting on March 12.
If you are aware of anyone who has not attended earlier ISO meetings and
so is not on Jeanne Martins mailing list but who is interested in
attending the Bonn meeting, please ask them to contact me also. The U.S.
expects to have a delegation of about 12; I would hope that the U.K. has
about 6.
Since the meeting in Geneva last April, TC97 of ISO has been reorganized
and Fortran has been allocated the number 5. This accounts for the change
from SC5/WG9 and from SC22/WG9 which you might also have seen used. I
have seen a draft copy of the minutes of the Geneva meeting; with luck
they will appear before July 1. Those who plan to attend the meeting
will be sent a copy of S8, the document containing all Fortran 8X proposals
so far, as they were following the X3J3 meeting of February 11-15.
The document itself will be ready in April.
Yours sincerely,
D.T. Muxworthy.
To: BCS, NAG, etc.
From: John Reid
Date: 15 February 1985
Subject: Report on X3J3 meeting at Monterey, 11-15 February 1985
l. Summary
The emphasis of the meeting was on proposals to correct errors
and omissions in the Fortran 8x language as it is now. There is a ban
on fresh technical proposals. The line between fixes to old features
and fresh proposals is somewhat blurred but the overall effect was
that a large number of small tidying-up proposals were accepted. The
fact that I am able to write this report in a self-contained way
without references to the full papers for details is indicative that
we were indeed considering simple tidying proposals. Despite this,
some significant array proposals were passed (see section 5).
The committee is showing some determination towards completing
its task but it has quite a long way to go yet.
2. Standing document S8
Subgroup time was concentrated upon checking the new Fortran 8x
language description document S8. Each author will handle his or her
chapter for one more meeting. Thereafter Walt Brainerd will commence
maintaining the whole document on his computer and typesetting it.
The next version will be used at the ISO meeting in Bonn.
An evening meeting discussed the document from an editorial point
of view. It was agreed that the present mixture of formal (bnf) and
informal descriptions is correct but that more examples are needed.
There was a discussion of the meaning of 'variable'. Currently
it is used for a scalar or an array that has a simple name. It was
agreed (12-7) to extend it to include a11 kinds of objects whose value
can vary at run time (e.g. array elements, sections, etc.).
3. Standing document S9
A new standing document S9, containing commentary from the
public and replies, has been started.
4. Fortran Information Bulletin 2
The second Fortran information bulletin, on interpretations of
Fortran 77, is still being processed by the committee's parent
organisation.
5. Array features
It was felt that new syntax is needed to provide straightforward
declarations of allocatable, automatic and alias arrays but a multi-
way straw-vote on alternatives was indecisive. A new proposal will be
put to the next meeting. My personal preference is for two new
attributes: LOCAL and ALIAS.
Dick Hendrickson asked whether the whole of array-valued
arguments to masked functions need be defined. For instance is
SUM(LOG(A),MASK=A.GT.0) allowed if A has some negative elements? No
decision was made.
After several straw votes explored alternatives, a new syntax
for the IDENTIFY statement was agreed (22-l). Examples of the new
syntax are the following
IDENTIFY(PART=STRUCTURE%COMPONENT(10))
IDENTIFY(DIAG(I)=A(I,I),I=l:N)
It was agreed (15-4) to disallow assignments to many-to-one
vector-valued sections for conformity with the rule for many-to-one
alias arrays.
Dick Hendrickson suggested that the notion of a contiguous (or
compact) array be introduced. This is an array-valued object whose
description would not demand a dope-vector. Passing an array-section
to a dummy argument declared as compact would either be illegal or
would require "copy-in, copy-out". These alternatives were both
rejected (8-10, 3-16, respectively). I voted against on the grounds
of the chairman's ban on fresh proposals.
It was agreed (20-1) to permit array-valued functions to return
allocated arrays as well as automatic arrays. Both are needed since
the use of allocatable arrays is much more powerful but is more
expensive at run-time.
It was agreed (21-l) that allocatable arrays should not be
allowed in data structures (the old standing document S7 does not say
anything on this point). The problem is that they would allow the
creation of a ragged-edge array which could be aliased with an
ordinary array by an IDENTIFY statement or passed as an ordinary array
to a procedure.
George Paul proposed an extra argument to the intrinsics
DOTPRODUCT and MATMUL to control the precision of the calculation.
Although an initial straw vote was favourable (17-4-12), the formal
vote was not (5-18) probably because the details need further
attention. Because I am working on these functions as author of
Chapter 12 of S8, I suggested working with George on a fresh approach.
George also proposed a new function for finding the location of
a maximum element of an array and a similar function for finding a
minimum element, and these were accepted (22-2).
Jerry Wagener proposed that a user-written function with scalar
arguments and scalar results be callable with array arguments as an
elemental function. If an overloaded array-valued function also
matches the call, the array-valued function takes preference. This
passed 16-5. It will be applicable to operators too and may
significantly simplify writing modules. For instance once '+' has
been defined for scalars it will automatically be defined for arrays.
6. Source form
Since a format may be a character expression, it was felt
desirable to regard the contents of a FORMAT statement as a character
expression with parentheses as delimiters (23-4-5). This will
simplify the continuation rules slightly.
It was agreed that underscore should continue to be regarded
alphanumeric but without a position in the collating sequence (21-3).
Much time was spent on getting suitable wording to describe null
statements, and the issue was finally resolved (17-7).
7. Double precision as generalized real
It was agreed (23-0) that double precision should be regarded as
a special case of generalized real in the same way as default (old)
real is.
8. Input-output
A straw vote on permitting non-significant underscores in
numerical input data (they are already allowed in constants) was
indecisive (14-12-9). One worry concerned whether to include them in
output data and, if so, where. Straw votes on removing the facility
from constants were also inconclusive (2l-13-4, 17-14-3, and for
voting members only 12-12-2).
No special facilities exist currently for input-output of
derived-type items. This is adequate for output since a function may
be placed in the output list, but is awkward for input. After
discussion it was agreed to leave things as they are for the present
(25-0-8), though the committee was less certain about leaving things
as they are for the final 8x language (12-5-16).
The question was raised as to what should be permitted for name-
directed (namelist) input-output of components and sections of arrays
and components of arrays. It was felt that the i/o list should
include array names (25-0-0), array elements with constant subscripts
(16-8-3) but not structure components (9-11-7), array sections (7-15-4)
nor array element with variable subscripts (l-21-5); also that a
subscripted data item should match an array-name in the list (18-0-4).
It was agreed (19-0) that name-directed input should treat upper
and lower case as equivalent within names in the data and name-
directed output should use upper case. It was felt that the absence
from the i/o list of a name in the data should be an error (23-0-1).
9. Bit data
The chairman is concerned about the likelihood of BIT, adopted at
such a late stage, delaying the whole standard and wished to consider
its deletion. However a straw vote favoured keeping BIT (20-10-6). I
voted in favour because I felt that a proposal to delete BIT would
violate her own ban on fresh technical proposals.
A notation for bit constants is needed and a straw vote favoured
B'0' rather than 0B (10-7-7), probably because it is more readily
extensible to octal and hexadecimal. It was agreed (18-5) to allow
the four forms B'0', B"0", B'l', and B"l".
It was agreed on a r01l-call vote (16-8) that the bit functions
BIT and INTB, which convert integer to BIT arrays and vice-versa
should be supplemented by similar functions that invert the bit order.
The four functions will be called BITLR, BITRL, IBITLR, IBITRL.
10. Subprogram parameters
Lawrie Schonfelder wondered whether PARAMETER should be extended
to include those items allowed in dimension declarators, so defining
subprogram parameters whose values remain fixed for the duration of
the call. The concept was liked (20-4-2), but worries were expressed
about changing the meaning of PARAMETER which currently defines
constants whose values are resolved at compile time. Having a
separate keyword was not favoured (14-8-5) perhaps because no
satisfactory suggestion was made.
11. A general facility for subscripting and substringing
Kurt Hirchert suggested adding syntax to allow any item of type
character to be substringed and any item of non-zero rank to be
subscripted. Current syntax does not include substringing an array of
type character (though it does allow substringing of a section, e.g.
C(:)(10:2O)) so an addition would be needed (e.g. C%(10:20)). The
idea was not favoured (2-13-1). I voted against on the grounds of
supporting the chairman's ban on fresh technical proposals.
12. Intrinsic functions
Lloyd Campbell proposed that the function TRIM, to trim trailing
blanks from a character item, be added. This was in S6 but by
oversight did not reach S7. It was proposed as a elemental function,
which does not work because all entries of a character array must have
the same character length. It was agreed (22-0-7) that it should
instead return the length excluding trailing blanks, but a formal
proposal was not available.
It was agreed (20-2) that SHAPE be extended to return a zero-
sized array for a scalar argument.
It was agreed (11-4) that REAL be extended to cope with
generalised precision conversions by adding an optional MOLD argument
whose precision and range determine the precision and range of the
result. After discussion it was agreed (12-2) that for CMPLX a
similar optional MOLD argument be added and that without it the type
attributes of the result be determined as for the arithmetic
operations.
13. Scope_of construct names
It was agreed that block construct names should be ordinary local
names, distinct from other local names (21-0). Any alternative would
have introduced a fresh scope (we now have scopes of (i) the whole
program, (ii) a program unit, and (iii) a single statement).
14. DO loops
It was agreed (22-5) that DO loops should not be extended
allow END IF, END WHERE, RETURN, STOP, GO TO, arithmetic IF, and
assigned GO TO as labelled loop terminators.
Jeanne Martin wanted to alter the semantics of EXIT and CYCLE so
that they are part of DO blocks and never refer to the control of a DO
loop, but this failed on a roll-call vote (10-17). The rule that an
unnamed EXIT or CYCLE statement refers to the innermost DO loop or DO
block, passed at meeting 86 but not currently incorporated into the
committee's standing document S7, was reaffirmed (22-0).
It was agreed to deprecate transfer of control to an END IF
statement from outside the block IF (23-0).
15. Next meeting
The next meeting will be in Urbana from May 6 to May 10. The
pre-meeting distribution deadline is April l.
DEC FORTRAN AND PROGRAM DEVELOPMENT AIDS
- TALK BY ERIC DAVISON (FROM DEES CUSTOMER SERVICES SUPPORT CENTRE)
1. WHERE DEC IS GOING WITH FORTRAN
(i) 65% of DEC systems worldwide use FORTRAN. Compilers
are available for the DEC 10/20 series, VAX (both under
VMS and ULTRIX) and the PDP-11 range.
(ii) VAX under VMS is most likely to have the first version
of '8X'. There is unlikely to be an implementation on
the DEC 10 series.
(iii) DEC operating systems are produced by 3 different groups
in the USA.
(iv) VAX - Technical Language Group (200 people) in Maynard,
Massachusetts develops Fortran, Basic; Pascal,
Lisp and Ada.
- Another group involved (which has a wider product
base as well) is "Commercial language and tools"
which provides Cobol and other languages plus a
layered environment for compilers. It also
maintains the run-time library (with a small sub-
group responsible for Fortran) and provides
I/O support.
(v) DEC's prime product for writing operating systems is BLISS.
This is influenced by Pascal, simple to learn and transportable
across DEC operating systems
BLISS-16 ... only for 16 bit systems
BLISS-32 ... for VAX
BLISS-36 ... for 36 bit systems
'Common BLISS' resembles a minimum subset of BLISS.
XPORT is a set of routines used for making simple ports of programs
Recently DEC have been writing some utilities in Fortran and Pascal
2. FEATURES OF DEC FORTRAN
(i) All DEC compilers comply with a minimum subset of F77.
Mostly they offer a superset. DEC 10/20s offer some
extensions which are not yet in VAX F77.
(ii) Ultrix (DEC's Unix implementation) offers the University of
Berkeley F77 compilers. DEC have not been satisfied with
it because it is slow and has contained too many bugs.
F66 can be called as an option from the same compiler
interface although the compilers themselves are separate.
(iii) TOPS 19 and 20 share the same Fortran compiler (full F77 with
extensions). A symbolic debuqqer for DDT is available.
(iv) VAX offers a full F77 implementation with extensions. A symbolic
debugger is available supported by all VAX languages. Mixed
language compilation is possible.
(v) New features offered by VAX Fortran version 4 include:
screen mode with source stepping
displaying all elements of an array
global optimisation
VAX Fortran is 9 pass. Switching the option off i.e. "no optimisation"
disables 6 of these passes. Compared with version 3, Vax Fortran
version 4 offers 50% improvement in code generated. There are
still some areas where optimisation has not yet been applied, in
particular the runtime library. But this will happen soon.
(vi) DEC have started work on VAX Fortran version 5. There will be
an equivalent Ultrix product but its name is yet to be decided.
Version 5 will offer improved optimisation by eliminating
code. DEC are seeking user feedback on what demand there is
for a compiler which gives up some optimisation capability in
return for a very fast compile phase.
(vii) IBM have been working on a product called NCRFTH which allows
more accurate arithmetic. DEC are interested in making routines
as accurate as possible and are looking at implementing something
similar as part of their run time library. They are also looking
at parallel processing possibilities.
3. FORTRAN '8X' - WHAT ARE DEC DOING?
DEC has two groups (32 bit/36 bit) working some distance apart looking at
how to implement '8X'. Some features proposed by X3J3 have already been
implemented. Within 8 months of '8X' being finalised DEC would expect to have
a product out on field trial.
4. UNIX
DEC have not been satisfied with Fortran on Ultrix. What they would like to do is
to take VAX Fortran and run it under Unix. Quite definitely they will provide
a high performance Fortran implementation under Unix, but with no definite timescales
committed.
5. GENERAL
(i) 65% of DEC sites use Fortran.
(ii) PASCAL is experiencing a big push and is preferred for teaching in
Universities.
(iii) DEC now offer an ADA compiler on VAXs. It has been successfully
certified by DQD using their validation test suite. No APSE is yet
committed.
(iv) PSRE are writing an ALGOL compiler for VAX.
(v) DEC offer a compiler option "/STANDARD" which prevents
using extensions which are not F77 standard conforming.
(vi) DEC bring out a major new version of Fortran compilers
about every 2 years. Maintenance releases appear every
3 months.
UNIVERSITY OF YORK
HESLINGTON, YORK, YO1 5DD
TELEPHONE 0904 59861
TELEX 57933 YORKU1
COMPUTING SERVICE 6 February 1985
John Wilson
Computer Laboratory
University of Leicester
Leicester LE1 7RH
Dear John Wilson
Fortran 77
I am writing to you in your capacity as Chairman of the BCS Fortran
Specialist Group to enquire whether you know of a F77 Standard checker.
What I am hoping to find is a program which will run on a DECsystem-10, possibly
written in F77, which will take a Fortran source program and syntax - check
it, producing a listing with all non-standard statements flagged.
Perhaps if you do not know of such a product yourself, you could ask the
membership under "Any other business" at the March meeting of the Fortran
Specialist Group.
I shall be grateful for your help.
Yours sincerely
Elisabeth Aylmer-Kelly
Can any Fortran SG member offer Elisabeth advice on this?
ANSI Fortran Committee X3J3
8th to 12th July 1985
The ANSI Fortran Standardisation Committee X3J3 will be meeting
at St. Catherine's College, Oxford from 8th to 12th July. This will
be its first meeting outside N. America. Harwell is hosting the
meeting and NAG has kindly offered reprographic facilities. Observers
are very welcome and are expected to participate in all discussions
and straw votes; they are excluded only from voting in formal votes
when decisions are made. However advance registration is essential so
that we can be sure that there is room. The committee will charge a
meeting fee of £30 (payable during the meeting) to cover the cost of
the room and refreshments.
Single-room student accommodation (without private bathrooms) is
available in the college for £15.50 per night including breakfast
(inclusive of VAT and service). Lunch each day at £5 and dinner on
Tuesday and Wednesday at £7 will be available to delegates and
spouses. For those wishing to lunch occasionally in college, we
suggest priority be given to Monday then Thursday. All college
accommodation and meals must be booked and paid for in advance. A
list of local hotels can be sent on request.
There will be an informal party (FIDS) at my house on Monday
evening and a formal dinner at the Randolph Hotel on Thursday at £15
(including VAT and service, but excluding drinks), when Professor Mike
Delves from Liverpool University will give an after-dinner speech.
Please complete the attached registration slip by 14th June at
the latest.
John Reid
--------------------------------------------------------------------------
To: J.K. Reid, Building 8.9, A.E.R.E. Harwell, Oxon OX11 0RA
From: ____________________________________________________________________
____________________________________________________________________
Please register me for the X3J3 meeting in July. I understand
that £30 will be payable to X3J3 during the meeting.
Number in my family that wish to attend
Monday FIDS _____ Thursday dinner (£15) ______
Please book the following college accommodation
Total
7 8 9 10 11 12
Bed and breakfast at £15.50. ____ ____ ____ ____ ____ ____
Lunch at £5 ____ ____ ____ ____ ____
Dinner at £7 ____ ____
Total ________
I enclose a cheque payable to UKAEA, Harwell for the college
accommodation.
Signed __________________________________