The following comment was sent late (after 2008-July-6) to
the f2008-ballot-comments-ext@Sun.com alias.

Commenter was Joe Krahn (krahn@niehs.nih.gov)
Commenter's Subject was "A few late comments"

I have a few minor comments, which may be useful even if it is really
too late for the public comment period:

For intrinsic procedures that return string values, such as ERRMSG, it
would be quite useful to allow ERRMSG to refer to an unallocated
allocatable string, which the procedure can automatically allocate to
the right length. Alternatively, there should be a way to query the
maximum length to avoid truncation, or a mechanism to access ERRMSG
strings via an integer error value for errors that have already occurred.


Also, I have a comment about one of the comments:

Robert Corbett commented on difficulties of type equivalences for
SEQUENCE derived types defined in separate sources, such as:

       module mod
         type t1
           sequence
           integer i
           type(t2), pointer :: p
         end type
         type t2
           sequence
           integer i
           type(t1), pointer :: p
         end type
       end

My suggestion to help resolve ambiguities is that type considerations
can use the idea of an "incomplete type" similar to typedefs in C, but
without depending on the type's name. So, when t1 is initially defined,
"type(t2)" can be thought of as "type(*)", and remains that way until
after type t2 is defined. For sequence-type equivalence, the t1
"signature" retains the "incomplete type" which was present when t1 was
initially defined.

This seems to be the most practical and straight-forward approach
without using complicated type recursion analysis. However, I don't know
if this would violate the equivalent type rules, because it would depend
on the order in which types are defined. In the above example, t1 and t2
would not be equivalent for the purposed of sequence-type matching.
Likewise, the initial definition of t1 could be equivalent in two
separate cases, followed by completely different t2 definitions. In the
scheme I propose here, t1 would still be equivalent sequence types
because the t2 pointer is considered an incomplete type reference at the
time it is defined.

It may not be necessary for the F2008 standard to explicitly define the
algorithm needed to distinguish sequence derived types, but it would be
good to have an example implementation worked out to ensure that there
is a reasonable approach that still fits into the type-matching rules.

Joe Krahn