(j3.2006) (SC22WG5.4636) Issue with C1255 in Interop TS

[Bill Long]

On 3/13/12 12:06 PM, John Reid wrote:
>
>
> N.M. Maclaren wrote:
>> On Mar 13 2012, Malcolm Cohen wrote:
>>>
>>>> It appears to me to be a good idea to enforce interoperable
>>>> type and type parameters for non-assumed-type dummy entities.
>>>
>>> Absolutely.
>>
>> The more I think about it, the more I agree. I think, however, that
>> this is a reason NOT to constrain assumed-type more than strictly
>> necessary.
>

I also agree (if not already obvious from earlier messages).

> We seem to be reaching consensus that along with my suggested change:
> Page 10, C1255, line 2, change "or" to
> ", a variable that has the ALLOCATABLE or POINTER attribute, a variable
> of assumed shape, a variable of assumed type, a variable of assumed
> character length, or".
>

assumed-rank?

Separately, I worry that the resulting sentence has the "does not have 
both the OPTIONAL and VALUE attributes" separated from the insertion far 
enough that it is not clear whether it applies.  Maybe if it were reversed:

"C1255 (R1229) If <proc-language-binding-spec> is specified for a 
procedure, each dummy argument shall be an interoperable procedure 
(15.3.7) or a variable that does not have both the OPTIONAL and VALUE 
attributes and is interoperable (15.3.5, 15.3.6),  assumed shape, 
assumed rank, assumed type, of assumed character length, or has the 
ALLOCATABLE or POINTER attributes."

> we need to add these constraints:
>
> C524a A coarray shall not be a dummy argument of a procedure that
> has a <proc-language-binding-spec>.
>
> C1255a A variable that not of assumed type and is a dummy argument of a
> procedure that has a <proc-language-binding-spec> shall be of
> interoperable type.
>

Right - those patch up holes created by the new C1255.

In a different email, Malcolm pointed out (in arguing for modifying 
C1255 instead of 15.3.5):

"These are not interoperable in the old sense of having the same 
representation, but in the new sense of having an automatic conversion 
between the Fortran entity and the C entity. "

This classification makes sense to me. My assumption is that 15.3.5/6 is 
intended to specify the "old sense".  If so, I think that the 15.3.5 
text might still need modification because of all the new capabilities 
we added.  The current para 1 of 15.3.5 is:

"A named scalar Fortran variable is interoperable if and only if its 
type and type parameters are interoperable, it is not a coarray, it has 
neither the ALLOCATABLE nor the POINTER attribute, and if it is of type 
character its length is not assumed or declared by an expression that is 
not a constant expression."

Among things that would appear to qualify as "interoperable" variables 
according to this:

1)  an assumed-type dummy argument associated with an interoperable 
effective argument.

2) an assumed-shape or assumed-rank dummy argument with type and type 
parameters that are interoperable.

Certainly the assumed-rank and assumed-shape cases come under the "new 
sense" of interoperable.  Assumed-type is different, but I think still 
not anticipated by the current text.

Cheers,
Bill


> Cheers,
>
> John.
>
>
>
> _______________________________________________
> J3 mailing list
> J3 at j3-fortran.org
> http://j3-fortran.org/mailman/listinfo/j3

-- 
Bill Long                                           longb at cray.com
Fortran Technical Support    &                 voice: 651-605-9024
Bioinformatics Software Development            fax:   651-605-9142
Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101