(j3.2006) J3 Fortran interp letter ballot #17 - due 25-Jul-2008

[Malcolm Cohen]

The following Fortran interpretations are being balloted:

Yes No Number Title

-Y- --- F95/0074 TARGET dummy arguments and POINTER expressions
-Y- --- F95/0102 mask-expr evaluated only once
-Y- --- F03/0049 Separators in list-directed output involving
UDDTIO
-C- --- F03/0071 Subroutine/function ambiguity in generics
-Y- --- F03/0073 C interop of dummy procedures
-Y- --- F03/0074 Type mismatch for C character arguments
-Y- --- F03/0075 C interop of derived types with array components
-Y- --- F03/0076 Scope of Fortran names of procedures with binding
labels
-Y- --- F03/0077 LBOUND of array structure component
-Y- --- F03/0081 F edit descriptor with field width 0
-C- --- F03/0082 VALUE in place of INTENT for pure procedure dummy
arguments
-Y- --- F03/0087 Entry names as dummy procedure arguments
-Y- --- F03/0098 Does allocate with source= define subcomponents?
-N- --- F03/0112 attributes allowed for dummy arguments in defined
assignments
-C- --- F03/0117 STOP executed via function in input/output list

General Comment:
Contrary to Van's position, I believe we should be silent on whether
F2008 will or will not have a new feature that would alter the
answer of any interp. These interpretation requests are all
specifically being answered in the context of Fortran 2003. Adding
some partial premature information to some answers could mislead the
reader into thinking we will never change the others in a future
standard: it just ain't so.

COMMENT F03/0071:
Jim claims that the argument is not at all "convincing", and wants
us to declare that the procedure call is ambiguous. That is less
than unconvincing: it is contrary to the expressed design principles
of generic resolution which were intended to make it impossible to
write an ambiguous generic reference. (Note: ambiguous means more
than one procedure matches.) Turning around and allowing some
generic procedure references to be ambiguous would be highly
controversial to say the least (to be consistent this would mean we
should be thinking of discarding most of our 16.2.3 rules on
disambiguation in favour of "sorting it out at the call site"!).

COMMENT F03/0082:
I disagree with Bill's comment about what "However" means; in this
case it clearly means "However, even though we didn't think about
it, ...". A bald "The standard is consistent" does not sit well
with the previous admission that we did not, in fact, think about it
in advance. Perhaps Bill would prefer "Nonetheless" to "However"?
As for the "no end date", I don't feel strongly about
it but all the answers are subject to change in a revised standard,
so it doesn't seem particularly useful to mention that here.

EDITORIAL COMMENT F03/0112:
DISCUSSION is for discussion of the background to the *answer*, and
is being used wrongly here. Furthermore the first paragraph is
mere pontification. Therefore:
(a) replace subtitle DISCUSSION with QUESTION;
(b) delete its first paragraph;
(c) delete subtitle QUESTIONS, replace following 1. with Q1. and 2. with Q2.

NO F03/0112:
My preference would be to revert to the answer in 08-163; this isn't
a deep issue, it's a "the standard allows you to do something silly"
question. Well, big deal. The standard allows you to write
INTERFACE ASSIGNMENT(=)
MODULE PROCEDURE s
END INTERFACE
...
SUBROUTINE s(a,b)
TYPE t
REAL x
END TYPE
TYPE(t),INTENT(OUT) :: a
TYPE(t),INTENT(IN) :: b
a = b
END
as well. It's impossible to call this in standard-conforming code,
ever; both as assignment, and as a direct procedure call. So what's
the big fuss over whether we allow POINTER/ALLOCATABLE on B? That
just makes it impossible to call in standard-conforming code via =,
so it's not quite as stupid as the example above (which no-one has
championed making illegal as far as I know).

If we must stick to the current answer's edit, the explanation with
the edit is badly worded (it's my fault: sorry about that).
Here is a greatly simplified alternative:

***BEGIN ALTERNATIVE ANSWER TEXT
ANSWER:

Yes to both questions. However, the allowance of ALLOCATABLE on the
second dummy argument was inadvertant; an edit is provided to make
this non-conforming.
***END ALTERNATIVE ANSWER TEXT

Finally, I must say it is quite disheartening to hear and read
restrictions on actual argument correspondance with dummy arguments
being brought up as if it had some bearing on whether, in the
absence of a specific invocation, a dummy argument is permitted to
have some attribute. The requirements for a procedure to be in an
INTERFACE ASSIGNMENT(=) block are emphatically NOT "in addition" to
the normal rules for argument association: the rules for argument
association have no bearing on the matter, because they only come
into play on procedure references. Being included into a generic
interface is not, in any way shape or form, a "procedure reference".

COMMENT F03/0117:
I agree with Jim that I overlooked the paragraph at [202:27-28].
Therefore, the third paragraph of the QUESTION "This ... 2003."
should be deleted.

Cheers,
-- 
........................Malcolm Cohen, Nihon NAG, Tokyo.