(j3.2006) 11-229 J3 Fortran interp letter ballot #24 - due 19-Aug-2011

[Robert Corbett]

J3 Fortran interp letter ballot #24 - due 19-Aug-2011

My votes for ballot 24 are:

Yes  No   Number     Title
-Y-  ---  F03/0017   Dummy procedure pointers and PRESENT
-Y-  ---  F03/0018   Multiple identical specific procedures in
                      type-bound generic
-Y-  ---  F03/0019   Multiple identical specific procedures in
                      generic interface blocks
-Y-  ---  F03/0021   What kind of token is a stop code?
-Y-  ---  F03/0046   Unlimited polymorphic pointers in common blocks
-Y-  ---  F03/0053   The BIND attribute for C_PTR and C_FUNPTR
-Y-  ---  F03/0065   Relational equivalence
---  -N-  F03/0084   IEEE_SET_ROUNDING_MODE in a subroutine
-Y-  ---  F03/0103   Restrictions on dummy arguments not present for
                      polymorphic type or parameterized derived type
-Y-  ---  F03/0116   indistinguishable specifics for a generic
                      interface with use association
-Y-  ---  F03/0118   Are lower bounds of assumed-shape arrays assumed?
-C-  ---  F03/0120   When are parameterized sequence types the same type?
---  -N-  F08/0055   G editing for reals
-Y-  ---  F08/0056   Non-polymorphic ALLOCATE with polymorphic SOURCE=
-Y-  ---  F08/0057   Interoperability with empty types
---  -N-  F08/0058   ENTRY point RESULT variable
-Y-  ---  F08/0059   Auto-targetting requirements
-Y-  ---  F08/0060   Procedure pointer assignment with an EXTERNAL target
-Y-  ---  F08/0061   Description of the CONTIGUOUS attribute misworded?
-Y-  ---  F08/0062   Mixing default initialization with DATA
                      initialization

--------------------------------

F03/0084

The answer given speaks of constant expressions
where the expressions in question do not satisfy
the definition of a constant expression given in
Clause 7.1.12 of 10-007r1.

---------------------------------

F03/120

The edit would be clearer if a comma were added
between "type parameters" and "and a
type-bound-procedure-part."


----------------------------------

F08/0055

Question Q6 includes an example that shows a
sequence of increasing values being written
and a sequence of values in mixed order being
written.  The question is is that result the
intended result, and the answer is no.  That
is technically correct, but misleading.  The
example given depends on the scale factor
being nonzero.  In general, when the scale
factor is nonzero, the number of significant
digits in values written in the form of an
F edit descriptor are different from the number
of significant digits in values written in
the form of an E edit descriptor.  There was
a recent e-mail exchange that dealt with this
issue.  If the number of significant digits
produced is different, the value can change
in either direction.  Consider the value 1.48.
It turns into "1.", "1.5", or "1.48" if
rounded to one, two, or three digits.

The edits speak of the "decimal exponent value,"
without giving a definition of the term.
Searching 10-007r1 turns up uses of the term
"decimal exponent," but they are context
dependent and two of them are clearly not what
is meant in the edits.  A definition of the
term that works is that the decimal exponent
value of a number N is FLOOR(LOG10(ABS(N)))+1.
While this looks bad in ascii text, it looks
better when expressed using Iverson's floor
notation and vertical bars for ABS.

------------------------------

F08/0058

This feature has been present since Fortran 90.
It is well defined.  A compiler that implements
ENTRY as required by F03/0110 should have little
trouble implementing this feature.  The proposed
edits make

      FUNCTION F
        H = 0.0
      ENTRY G RESULT(H)
        H = 1.0
      END

nonconforming, while F03/0110 asserts that

      FUNCTION
        G = 0.0
      ENTRY G

is conforming.  Users are bound to be confused
by the different treatment of these similar
cases.