BRITISH COMPUTER SOCIETY - FORTRAN SPECIALIST GROUP

Minutes of Meeting Held at BCS HQ on 10 June 1985

Present:        I D Hill           - MRC

                Chris Lazou        - ULCC

                Brian Meek         - QEC

                Keith Normington   - Coventry Polytechnic

                Mike Nunn          - CCTA

                John Wilson        - Leicester University

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

1.      Apologies for Absence

Apologies were received from John Reid (Harwell), David Muxworthy

(Edinburgh University), Lawrie Schonfelder (Liverpool University) and

Dave Vallance (Salford University).

2.      Minutes of Last Meeting [11 March 1985]

        (i)     Corrections

                Page 2 paragraph 1:

                "David Maxworthy" should read "David Muxworthy".

                Page 2 "Matters Arising"

                David Hill has discovered that at the time of the March

                meeting, the BSI Standard document "Method of Specifying

                Requirements for FORTRAN Language Processors" had yet to

                go out for public comment.

3.      Matters Arising

        (i)     It was agreed that the Secretary should invite someone from

                NCC to give a talk on Fortran compiler validation at our

                September meeting.

        (ii)    The Chairman would send details of the Group's meetings to

                Computer Weekly for publicity purposes.

        (iii)   The Chairman would be writing to individual members seeking

                views on the future of the Group, and the content of meetings in

                particular. Recent attendances had been very disappointing

                and members could not expect to adopt a completely passive

                role with the Group's existence depending on a lot of effort

                by a relatively few members who regularly attend meetings.

        (iv)    Suggested talks at future meetings included:

                December 1985 - John Reid (Harwell), who attends X3J3 meetings

                to talk on areas of "8x" of particular interest to the Group.

                March 1986 - a panel discussion with 6 people to recount their

                experience with Fortran on micros.

                [Any other suggestions for future talks should be sent to

                the Secretary]

4.      X3J3 Progress

On this occasion none of the regular UK attendees at X3J3 meetings was able

to be present to talk about recent "8x" progress. However, John Reid

(Harwell) has supplied an in depth account of the most recent X3J3 meeting

at Urbana, 6-10 May 1985. (See Appendix A1). [Thanks again John]. "8x"

would of course be the subject of the July 1985 "Fortran Forum" organised

by the Group in London. Would anyone with views on the content of "8x"

please complete questionnaire supplied by John Reid in Appendix E.

5.      BCS Business

        A detailed statement of the Group's accounts for the last financial year

        appears in appendix B.

6.      "Fortran Forum 85"

"Fortran Forum 85" organised by the Group would take place at the

Institute of Education, London on 15th July. Leading members of

X3J3 who had been attending the first X3J3 meeting outside North

America at Oxford (see Appendix A2) would be presenting the contents of

the forthcoming standard "Fortran 8x".

Compared with the published programme (see appendix C) there would be

two changes viz

  (i) Neldon Marshall.would give the "8x" overview instead of Walt Brainerd

 (ii) Lawrie Schonfelder would talk on "numeric precision" instead of

      "deprecated features".

[NB. "Fortran Forum" took place very successfully with a large, enthusiastic

turnout and will be discussed at next Group meeting and in next newsletter -

Sec].

7.      Any Other Business

NCC have recently produced validation reports on the Fortran 77 compilers

from Salford University (for Prime Systems), Norsk Data (for NORD-100 and

NORD-500 systems) and Acorn.

Copies of the reports are available for free on application to:

        Vony Gwillim

        Senior Consultant

        Standardisation Office

        The National Computing Centre Ltd

        Oxford Road

        Manchester M1 7ED                        Tel: 061 2286333

8.      Date of Next Meeting

The next meeting of the Group will be held on Monday September 16th 1985

from 10.45 am to 4.00 pm in Room E201 Birkbeck College, London.

In the afternoon, David Littlewood of NCC will give a talk on how the

NCC/FSTS Fortran compiler testing service operates.

9.      BSI Standard - "Method for Specifying Requirements for Fortran Language

in appendix D.

MIKE NUNN

Secretary

20 August 1985

APPENDIX A1

To:          NAG, BCS, etc.

From:        John Reid

Date:        17 May 1985

Subject:     Report on X3J3 meeting at Urbana, 6-10 May 1985

References:

[1]   94(*)RWW-1 Proposal to organize two task groups

[2]   94(*)EAJ-1 Surveys

[3]   93(*)JCA-S9-1 SAIC report to J3 on reliability problems

[4]   94(18)AW/JKR-1 Changes to Section 12 of S8

[5]   94(*)KH-1 Method of paring S8

[6]   94(*)KH-2 Trial set of operating principles.

1.      Summary

        The meeting itself, and work before the meeting, was dominated

Dick Weaver's proposal (see paragraph 2) to divide the committee

into two task groups. Dick 'phoned all members in order to stimulate

discussion and conduct his own straw poll. The steering committee was

unanimously opposed and responded by redoubling its efforts to produce

the draft standard, S8 (see paragraph 6). The proposal failed (8-25),

and a task group was set up to explore other ways of reducing the size

of the language. It will bring a proposal to the next meeting.

        The rest of the time was largely spent on detailed consideration

of S8. By the end of the meeting the committee was its usual cheerful

self, choosing to accept both Lloyd Campbell's alternatives for

trimming trailing blanks from character expressions rather than one of

them.

        Please note that this is a personal view of the meeting and in no

sense an official record.

2.      Weaver proposal for two task groups

        Dick Weaver proposed that the committee should divide into two

task groups and produce two standards. 'Revised Fortran' would be

upwards compatible with Fortran 77 and contain, in general, array

features, numeric precision, bit data, i/o enhancements, F77

clarifications, CASE, call statement enhancements, IMPLICIT NONE, and

block DO. 'Modern Fortran' would consist of revised Fortran (either

with or without deprecated Fortran 77 features) plus the rest of

Fortran 8x, that is plus modules, internal procedures, recursive

procedures, derived data types and exception handling.

        The committee was seriously divided on this issue. Most of the

vendors favoured it strongly because of wanting a less major and fully

compatible extension of Fortran 77. The users (and a few vendors)

were not convinced that 'Modern Fortran' would be taken seriously and

therefore saw the proposal as a major reduction in the power and

utility of Fortran 8x. No one spoke of this proposal as a means of

speeding the eventual adoption of the whole of Fortran 8x. Several

disapproved of any attempt to split the language into subsets.

        An initial straw vote among members only was 11-2O-4 and after

spending most of Monday in full committee discussing the issue, a

further straw vote was virtually identical (11-20-3). Weaver then

petitioned for the issue to be resolved by a postal vote of all

members. Under X3 rules, such a petition must be signed by five

members and four of Weaver's supporters promised to do so. I felt

that this was a disastrous outcome. The issue would not be resolved

for at least two months, during which time no serious attempt would be

made to look for a proposal that might meet general approval. It

would be very hard during the rest of the meeting and in the interval

before the next meeting for the committee to concentrate with energy

on the urgent task of writing its draft standard, S8. However

overnight at least one of the petitioners, Ned McCall, withdrew his

support from the petition and it was not presented. A roll-call vote

was taken on Tuesday morning and the proposal failed 8-25.

3.      Surveys

        In an attempt to address Weaver's points, the committee members

were asked to complete a survey sheet which asked for votes on whether

the language is too big, which of a list of features might be deleted,

and which of the deprecated features should be retained. I found this

very hard to complete because I thought that a well-researched proposal

for careful pruning was needed rather than a hasty proposal for

wholesale lopping of a few features. In the end I said this and voted

only for removal of vector-valued array sections (I believe that their

functionality would be much better provided as a pair of intrinsic

functions, but my last year's proposal for this failed). On the

deprecated features, I tried a new criterion: include only those for

which a replacement is available in Fortran 77 (this is based on the

feedback I am getting re deprecation). The results of the survey are

given in attachment I to [2]. Based on this survey and the FIB

survey, Andy Johnson [2] proposed

        (1)  Remove DO from deprecated list (see paragraph 10, below)

        (2)  Remove nX editing from deprecated list.

        (3)  Remove keyword arguments from Fortran 8x.

        (4)  Remove condition/enable from Fortran 8x.

        (5)  Remove vector-valued subscripts from Fortran 8x.

        (6)  Remove variant structures from Fortran 8x.

        (7)  Remove insignificant blanks from deprecated list.

This proposal was not put because it was not in the pre meeting

distribution, but a straw vote was favourable (25-5-5). Another straw

vote showed that the committee feels that the language is too large

(24-10-4) and would still be too large if Andy's proposal had been

passed (19-10-5).

        A straw vote asking whether there should be any subsets gave the

answer 'no' (6-23-8).

4.      Task group op reducing the size of Fortran 8x

        A task group was formed to consider how a comprehensive proposal

to reduce Fortran 8x might be formulated, and it met in subgroup time.

It proposed the adoption of a set of operating principles and that

each present 8x feature and any incoming feature should be judged

against these principles. The group hoped in this way to formulate a

comprehensive proposal for the reduction of 8x. This would be voted

as a whole, rather than piecemeal, in view of the failure of the hit-

list approach. References [5] and [6] discuss the approach in more

detail. The proposed operating principles, in priority order, were

        (l)  Compatibility with F77

        (2)  Standardization of existing practice

        (3)  Performance

        (4)  Functional capability

        (5)  Completeness

        (6)  Ease of implementation

        (7)  Fortran-like

        (8)  Timely adoption of the standard.

Not everyone agreed on the list and the order of priority. Indeed one

actually wanted the order to be reversed. I complained about the

omission of safety (though reliability and maintainability were

mentioned as sub-sub-headings of (4), under the sub-heading of

'compile-time'). No formal decision on adoption of these principles

was made, though a comprehensive proposal to reduce 8x will be put to

the next meeting.

5.      Berns presentation on reliability

        Gerry Berns wrote a thoughtful letter [3] to the committee and

was asked to present his ideas as a tutorial. He wishes changes to be

made to Fortran 8x based on his experience with a static program

analysis tool, MAT. His wish is for standard Fortran programs to be

inherently more reliable and therefore maintainable. He does not like

Fortran 77's treatment of violations of prohibitions as being

extensions. He wants

        (1) any program unit containing a new feature also to contain

        IMPLICIT NONE (this permits the compiler to pick up typing errors

        that otherwise read as valid Fortran)

        (2) there should be a standard default value for variables

        referenced without being set (he suggested -1, but discussion

        favoured "not-a-number" (NaN) on machines

        (3) "clutter" (variables and entries that are never used)

        should be identified as errors

        (4) all global names should be distinct throughout the program

        (this was felt to be an unreasonable restriction, since several

        independently developed modules might be used together).

        I will make a proposal on conformance to the next meeting, but in

general the committee did not appear to favour these ideas.

6.      Document processing

        Most of the subgroup time was spent looking at the draft

document in detail, though the Weaver proposal resulted in much more

time being spent in full committee than was originally planned.

        The committee passed (29-0) Alan Wilson's and my minor changes

[4] to the intrinsics.

        Kurt Hirchert discussed a large number of proposals that arose

from writing the chapter on procedures, but no formal votes were

taken.

        Dick Weaver proposed a change in the way the term 'subscript' is

used, so that an array element is referenced with a list of subscripts

rather than a subscript consisting of a list of subscript expressions.

This is in line with usual practice outside the F77 standard itself

and was accepted (23-0).

        Dick Weaver also proposed that the term 'variable' be used for

any assignable object with a simple name. His proposal.failed (5-11),

probably because of uncertainty over the way components of structures

are regarded.

        The first fully typeset version of S8 was circulated at the

meeting, but was rather full of typographical and substantial errors.

A revised version will be sent to participants at the Bonn and Oxford

meetings in July.

        The chairman hopes to complete S8 by the meeting in November

this year.

7.      Array features

        There was a discussion as to whether there should be specific

declarations for automatic, alias and allocatable arrays. It was

decided not to do so for automatic arrays (9-13) but to do so for

allocatable (21-5) and alias (28-2) arrays. George Paul suggested

that ALIAS should be 'spelt' IDENTIFIED but his amendment failed (8-21).

I was strongly opposed to this apparently innocuous amendment

because the description of the IDENTIFY statement was carefully

rewritten about two years ago and 'alias' was the best word that we

could summon them to label the object created.

8.      USE statement syntax

        Jerry Wagener proposed that the USE statement syntax be altered

so that slashes are not needed around the module name. Example of the

new syntax are

        USE MATH_LIB

        USE MATH_LIB ALL EXCEPT (ML_X15)

An optional comma after the module name was favoured (15-2-11) and the

proposal passed (24-0).

9.      Input-output

        Vector-valued sections are irregularly spaced in storage and may

therefore cause inefficient i/o processing. A proposal to disallow

them as units for internal files passed 17-9, but a proposal to

disallow them in input lists failed 6-22. A straw-vote did not favour

disallowing them in formats (2-24-4).

        The following minor changes were accepted (28-0):

        (1)   Allow REWIND on a file that does not exist.

        (2)   Allow IOSTAT and ERR specifiers to change for an OPEN on a

        file already open.

        (3)   Disallow underscore in a format except within an

        apostrophe, quote or H edit descriptor.

It was agreed that truncation on internal file writes be treated as

for character assignment (14-7).

        There was a discussion on how namelist i/o should handle derived

data. The sentiment favoured allowing a wide variety of forms in the

input, but with some irregularity (13-0-3). Allowing array sections

was not favoured (4-2-10), while keeping it extremely simple (simple

names only in input) was not favoured either (6-3-8).

10.     New DO

        Jerry Wagener proposed a new form for the DO, which essentially

includes the DO loop and DO block as special cases. The committee

favoured the approach strongly (24-0-2).

ll.     Functions for trimming trailing blanks

        Lloyd Campbell proposed two functions for trimming trailing

blanks from character expressions. One, applicable only to scalar

character expressions, returns the trimmed string; the other is an

elemental function (hence applicable also to arrays) that returns the

trimmed length. These were originally proposed as alternatives but a

straw vote favoured both (3 for the first, 3 for the second, 14 for

both and 5 undecided). The first passed 21-1 and the second 12-10.

12.     Future meetings

        To speed up the writing of the draft standard, S8, there will be

an extra meeting in September and five meetings in 1986. The full

schedule is:

1985:       July 8-12, September 9-13, November 11-15.

1986:       January 20-24, April 7-11, June 16-20, August 25-29,

            November 10-14.

The next pre meeting distribution deadline is June 3.

APPENDIX A2

To:          BCS. NAG, etc.

From:        John Reid

Date:        14 July 1985

Subject:     Report on X3J3 meeting at Oxford, 8-12 July 1985

References:

[1]    95(17)JKR-6   Renaming keywords for generalized real

[2]    95.JLW-1      DO loops

[3]    95(14)JKR-3   Conformance

[4]    95(15)JKR-4   Implicit none

1.      Summary

        This meeting was free from any major controversy and

concentrated on minor technical clean-ups (most of which I will not

report here) and on work in subgroups on checking individual chapters

of the standing document S8, in preparation for its release for public

comment after a few more meetings. It was agreed (26-0) to regard S8

as the basis document and require all new proposals to be phrased in

terms of amendments to it. S8 is not yet ready to be regarded as a

statement of all the proposals that have been passed, and changes are

still being made in an informal manner by subgroups and the editorial

committee.

        The number of members and observers was very similar to that of

a meeting in USA.

2.      Renaming keywords

        My renaming proposal [1] was divided into two proposals. The

committee accepted (23-0) renaming the function PRECISION as DIGITS,

the function ACTUAL_PREC as ACTUAL_PRECISION and the attribute keyword

PRECISION10 as PRECISION. This means that the generalized precision

attributes are named PRECISION and EXP_RANGE and the functions that

return the actual values (which are never smaller) are called

ACTUAL_PREC1SION and ACTUAL_EXP_RANGE.

        My offer, with Peter Kirby, to review all the keywords was

accepted.

3.      DO loops

        Jerry Wagener's proposal [2] for a new DO loop that contains the

old DO and the new DO as special cases was accepted (20-3).

4.      Masked array intrinsics

        There was another discussion, but no resolution, of how to

interpret such expressions as

                        SUM(A/B.MASK=B.NE.0.)

A 4-way straw vote was as follows:

        Must evaluate all terms            7

        Must not evaluate masked terms    11

        Processor dependent               14

        Undecided                          7

5.      Size of the language

        The task group looking at the size of the language decided to

recommend some changes to the deprecated features (see next section of

this report) and the deletion of just two features, keyword arguments

and vector-valued subscripts. On keyword arguments, a four-way straw

vote went as follows

        Remove completely                  0

        Use only with intrinsics           5

        Keep                              28

        Undecided                          2

A straw vote of 16-9-9 favoured removal of vector-valued sections, so

I will "dust off" my proposal of last summer.

        To the question "is the language too large?" a straw vote replied

"no" by 5-27-6.

6.      Deprecated features

        The task group on the size of the language recommended the

removal from the list of deprecated features of any item whose

functionality is equal to that of its replacement. In particular they

wished to "undeprecate" DIMENSION, x-editing, and insignificant

blanks. On DIMENSION, the straw vote was divided (16-17-5). The

committee agreed to remove x-editing from the deprecated list (18-5)

because it is so widely used. It did not want to undeprecate

insignificant blanks (14-21-2).

7.      Compatibility_with F77

        It was agreed (24-0) to add a statement at the very front of S8

that the committee's intent was for F77 programs to conform to F8x.

8.        Conformance

        I made two substantial changes to my paper [3] on conformance,

following discussion in subgroup:

        (a) deletion of the requirement to provide a warning if an

interpretation is given to a form or relationship beyond those

specified in the standard.

        (b) abandon the attempt to distinguish between "absolute" and

"execution" requirements and instead require the processor to specify

how its treats each requirement.

Change (a) was introduced because the requirement might demand very

subtle diagnostic checks to be made and we could not see how to

distinguish straightforward extensions (e.g. fresh syntax) from subtle

semantic extensions. Change (b) means that we are not restricted to

static errors and should avoid much committee discussion of details

        The full committee was broadly favourable (initially 14-6-9 and

after discussion 13-4-17). It was felt (l-15-17) that a list in an

appendix did not need the support of comments in parentheses in the

text. There was some sentiment for detaching the language definition

from the requirements imposed on processors. Regret was expressed

that change (a) deleted any requirement for a "FIPS style" check.

Concern was also expressed over the work involved in constructing the

list in the appendix. It was pointed out that the more requirements

are imposed on standard conforming processors, the less of them there

are likely to be.

9.      Implicit none

        Following a presentation by Gerry Berns at the last meeting, I

proposed [4] some changes in connection with implicit none. Gerry

believes that "far and away the worst feature of Fortran, from the

standpoint of attributable errors, is implicit data typing" and

suggested that IMPLICIT NONE be required in any program unit that does

not conform to Fortran 77. Currently IMPLICIT NONE is the default if

a USE ALL statement is present without an IMPLICIT statement.

        In general the committee felt that it has gone far enough in

that IMPLICIT NONE was available for use by those that like it. There

was some sentiment (14-12-5) for deprecating the use of implicit

typing other than in the presence of an IMPLICIT statement. A straw

vote on the proposal that an internal procedure without an IMPLICIT

statement should be interpreted as if IMPLICIT NONE were present was

negative (8 15-10). I did not ask for straw votes on the other

proposals since I felt that they were even less likely to be favoured.

10. Next meeting

        The next meeting will be at Los Alamos, Sept 9-13. The pre-

meeting distribution deadline (for receipt in USA) is Aug 5.

 APPENDIX B

THE BRITISH COMPUTER SOCIETY

  FORTRAN SPECIALIST GROUP

Receipts and Payment Account for the year ended 30th April 1985

   (Please submit to HQ by 1st May)

('A' and 'B' should agree)

Please enclose bank statement (or copy), and a list of outstanding cheques.

APPENDIX C

[Programme of "Fortran Forum 85" held on 15th July 1985 in London]

  PROGRAMME

                    09.45         Registration and Coffee

                    10.15         Introduction

                                  John Reid

                    10.20         Development of Fortran 8x

                                  Jeanne Adams

                    10.40         Overview of Fortran 8x

                                  Walt Brainerd

                    ll.40         Array Features

                                  Alan Wilson

                    12.40         Lunch

                    14.00         Data abstraction

                                  Jerry Wagener

                    15.00         I/O Extensions

                                  Jim Matheny

                    15.30         Tea

                    15.50         Deprecated features

                                  Lawrie Schonfelder

                    16.10         Panel Discussion

                                  (Panel members: all X3J3

                                  members present)

                    17.00         Close

APPENDIX D

BSI STANDARD "METHOD FOR SPECIFYING REQUIREMENTS FOR FORTRAN LANGUAGE

PROCESSORS"

Talk by Brian Meek (Queen Elizabeth College and BSI Committee)

        (i)     The objective of the new BSI Standard "Method for Specifying

                Requirements for Fortran Language Processors" is to develop

                a Standard for writing specifications for Fortran language

                processors. It makes no attempt to produce anything which is

                in conflict with the ANSI Standard for Fortran. It tells the

                user how to write a specification for what he requires from

                a Fortran language processor.

        (ii)    The new Standard can be used in several ways viz:

                - designing a processor [the user suppliers the implementor with

                  a specification of what to do].

                - procurement [buying a Fortran processor]

                - testing/evaluating Fortran processors comparatively [this would

                  supplement the FSTS/NCC validation reports].

        (iii)   The draft Standard was approved by the OIS/5 committee

                last December as ready to go out for public comment but has been

                somewhat held up subsequently at BSI.

        (iv)    How does the Standard work?

                - introductory bits

                - scope

                - definitions

                - what one should put in a specification

        (v)     The ANSI Fortran Standard defines:

                - forms of programs

                - rules of interpretation

                - input/output data formats

                but excludes:

                - result when rules fail to interpret a program

                - specification of size, complexity of program and data

                - rules for range and precision.

                The new BSI Standard addresses these latter areas. It emphasises

                strict adherence to ANSI and that rules should not be bent. A

                eg. if a processor uses unorthodox storage association to

                acquire greater efficiency then it is non-standard.

        (vi)    Other areas given particular attention are:

                - ranges of numbers

                - collating sequences

                - order of evaluation

                - depth of nesting of constants

                - minimum level of complexity (nos. of arguments, etc)

                - requirements on error (statistically checkable) and exception

                 detection, reporting and recovery (if any).

        (vii)    Language extensions:

                The BSI Standard says that if you must have extensions then write

                them down in same way as if they had been in ANSI Standard. It

                also insists that a processor flags extensions and, if possible,

                converts them into a Standard form.

        (viii)  Validation:

                Users are reminded to put in such requirements and that validation

                processes exist.

        (ix)     How will the new Standard be used?

                [Brian Meek described this in a "Computer Weekly" article,

                (ref: WG9/16)].

                Either - in full for producing a rigorous specification

                       - as above but omitting parts not important to the user

                       - as a checklist, where user is looking for particular properties

                       - as a checklist, for language processor implementors.

        (x)      The new Standard would have potential to be adopted as a pattern

                for specifying requirements for other language processors,

                eg. PASCAL.

Final Note

Members of the BCS Fortran Specialist Group interested in this new Standard

are recommended to write to BSI asking to be put on the list of people to

receive a copy as soon as it is published (or in the meantime approach

one of the BSI committee members such as Brian Meek for a pre-printed

version). There is no certainty when the BSI draft will be available but

the public comment period will last 2-3 months.

APPENDIX E

   Fortran Forum, July 15th 1985

        Here is a copy of the questionnaire that was mentioned at the

Fortran Forum. It was originally published in "Status of work toward

revision of programming language Fortran" by J.L. Wagener. This was a

special issue of SIGNUM Newsletter (Vol. 19, No.3, July 1984) and a

special issue of FORTEC Forum (Vol.3, No.2, June 1984) and contained a

summary of Fortran 8x at that time. Yesterday's Forum should have

given you enough data to answer most of the questionnaire, though it

was not possible to cover everything; for instance we said nothing

about the enhanced call or event handling. Please leave a line blank

if you don't know enough about the feature to have an opinion.

        Thank you for showing an interest in Fortran 8x and for coming

to the Forum.

                                                 Yours sincerely,

                                                 John Reid,

                                                 CSS Division,

                                                 Building 8.9, A.E.R.E.

                                                 Harwell, Oxon OX11 0RA.

Enc:

FORTRAN 8x SURVEY

FORTRAN STANDARDS COMMITTEE X3J3

   Jeanne Adams, Chair, X3J3

This questionnaire has been developed to survey the Opinions of

the user community on the new features and the architecture

proposed by X3J3 for inclusion in the next draft FORTRAN

standard. The results of this and other surveys and question-

naires will be used by the X333 committee in assessing the

strength of each new facility for inclusion in a draft standard.

Information about the new features is contained in "FORTRAN

Information Bulletin", Number 1. Return your questionnaire to:

        Andrew Johnson

        MS 10C17-3

        Prime Computer Inc.

        500 Old Connecticut Path

        Framingham, Ma 01701

RESPONDENT PROFILE

Check those that apply.

Type of Organization:               Are you employed as:

     Scientific       __________         Professional Programmer      _______

     Engineering      __________         Problem Solver (Occasional)  _______

     Commercial       __________         Compiler Writer/Implementor  _______

     Government       __________         Home Computer User           _______

     Vendor (Computer)__________         Manager of Software          _______

     University       __________         Other                        _______

     Other (state)______________

Was FORTRAN your first computer language? Yes____  No ____

What is your "language of choice?" _______________________

Name the vendor and operating system currently used.

        ______________________________________________

Do you now use: FORTRAN 66 _______  FORTRAN 77 _______   77 Subset ___________

Do you subscribe to: FORTEC ________ SIGPLAN _________    SIGNUM   ___________

Have you seen the FORTRAN Information Bulletin summarizing the

proposals currently under Consideration for FORTRAN 8x? Yes _____  No _____

List two features for FORTRAN 8X that--

You want in FORTRAN:                        You do not want in FORTRAN:

1. _________________________                1. _______________________

2. _________________________                2. _______________________

===============================================================

Name _____________________________        Address ________________________

Tel. No.__________________                ________________________________

CHECKLIST ON FORTRAN 8x FEATURES

                          |Strong1y |         |Do not   |Strongly  |Don't

                          |Approve  |Approve  |Approve  |Disapprove|Care

                          |_________|_________|_________|__________|___

Array Processing Features_|_________|_________|_________|__________|___

WHERE Construct___________|_________|_________|_________|__________|___

Data Structures___________|_________|_________|_________|__________|___

New Source Form(free)_____|_________|_________|_________|__________|___

Significant Blanks________|_________|_________|_________|__________|___

Recursion_________________|_________|_________|_________|__________|___

Precision Specification___|_________|_________|_________|__________|___

Environmental Intrinsics__|_________|_________|_________|__________|___

Loop Constructs___________|_________|_________|_________|__________|___

Enhanced CALL_____________|_________|_________|_________|__________|___

CASE Construct____________|_________|_________|_________|__________|___

Internal Procedures_______|_________|_________|_________|__________|___

IMPLICIT NONE_____________|_________|_________|_________|__________|___

Entity Oriented Decl. ____|_________|_________|_________|__________|___

Derived Data Type_________|_________|_________|_________|__________|___

MODULES___________________|_________|_________|_________|__________|___

Event Handling____________|_________|_________|_________|__________|___

Varying CHARACTER Length__|_________|_________|_________|__________|___

(Note it has been removed)

Bit Data Type_____________|_________|_________|_________|__________|___

Macros (Note that it

has been removed)_________|_________|_________|_________|__________|___

Architecture with deprecated

Features (next page)______|_________|_________|_________|__________|____

========================================================================

General Impression

of FORTRAN 8x_____________|_________|_________|_________|__________|___

DEPRECATED FEATURES

Which of these features would you make a candidate for deletion

in the 199X FORTRAN standard, note FORTRAN 9x. All of these

features will be retained in 198x. Do you want these removed

from 199x, retained in 199x or are you undecided? Check one.

                                               Removed|Retained|  Unde-

                                                from  |  in    |  cided

                                                199x  | 199x   |

FORTRAN 77 Fixed Position Source Form          _______|________|________

Alternate RETURN                               _______|________|________

Assumed Size Dummy Arrays                      _______|________|________

Passing Scalar to Dummy Array                  _______|________|________

Specific Names (not Generic) for Intrinsics    _______|________|________

Statement Functions                            _______|________|________

BLOCK DATA Program Unit                        _______|________|________

Arithmetic IF Statement                        _______|________|________

ASSIGN and Assigned GO TO Statements           _______|________|________

COMMON Statement                               _______|________|________

Computed GO TO Statement                       _______|________|________

DATA Statement                                 _______|________|________

DIMENSION Statement                            _______|________|________

DOUBLE PRECISION Data Type                     _______|________|________

ENTRY Statement                                _______|________|________

EQUIVALENCE Statement                          _______|________|________

FORTRAN 77 DO Statement                        _______|________|________

PAUSE Statement                                _______|________|________

Please include any comments you wish to make concerning FORTRAN

8x features and features marked as candidates for deletion from

FORTRAN 9x on the reverse side of this page.