ISO/IEC JTC1/SC22/WG5-N1397
 

              SUGGESTIONS FOR THE WG5 MEETING IN OULU
                          (Alla Gorelik)

I.  Minor Technical Enhancements to be included in addition to N1382.
II. COMMENTS TO 1539-3

---------------------------------------------------------------
                                I
Minor Technical Enhancements to be included in addition to N1382.
                          (Alla Gorelik)

1. Greater than seven dimensions
   (see N1189 items #24, #24a).
   Rationale.
   Some applications require more than seven dimensions.

2. Extend the semantics of an EXIT statement
   (see N1189 item #25).
   Rationale.
   To extend the semantics of an EXIT statement to allow its using
   for an exit from any control constract.
   This is useful for better structural style and for
   regularisation of Fortran features.

   For example

    SELECT CASE ( . . . )
        CASE ( . . . )
        . . .
        IF ( . . . )  GOTO 6
    ! Better IF (. . . ) EXIT
        . . .
        CASE ( . . . )
        . . .
    END SELECT
  6   . . .

3. Unsigned INTEGER Data Type
   (see N1189 item #37).
   Rationale.
   It is useful for interoperability between Fortran and C.

4. Features to be declared obsolescent in Fortran 2000.
   I believe it is time to extend the obsolescent list with following
   elements:
   the old forms for the relational operators,
   DOUBLE PRECISION statement,
   ENTRY statement,
   BLOCK  DATA  subprogram,
   storage associations,
   association scalar actual  argument  and  array  dummy  argument
   (see Fortran 95 standard 12.4.1.4.).

5. Features to be deleted.
   In my opinion, all features of Fortran 95 that were obsolescent
   (Fortran 95 standard, Annex B.2) with the exception of fixed form
   source may be deleted.

-------------------------------------------------------------------
                                II
                        COMMENTS TO 1539-3
                          (Alla Gorelik)

1. In 6.1 the first phrase is:
  "A coco block is a sequence of coco directives, coco comment lines,
   coco INCLUDE lines and noncoco lines that . . . "

  CCR601  coco-block   is  [pp-input-item]...
  But
  CCR202  pp-input-item  is  coco-construct
                         or  noncoco-line
  (neither  coco INCLUDE lines nor coco comment lines).

  In this connection  I suggest to correct the first phrase in 6.1
  or (more preferably) to add to CCR202 one line:
                       or  coco-include-line
  and to add a rule for coco-include-line.

2. Page 17, Section 9. First and second constraints after CCR902.
   In my opinion   would be desirable replace the words "coco directive"
   (twice) by "coco-type-declaration-directive".