(j3.2006) Vote on letter ballot on N1866

[Bill Long]

On 7/11/11 7:07 PM, Van Snyder wrote:
> Bill Long wrote:
>> On 7/11/11 3:12 PM, Van Snyder wrote:
>>
>>>                                           ISO/IEC JTC1/SC22/WG5 N1867
>>>
>>>                        WG5 letter ballot on N1866
>>>
>>>                         John Reid, 7 July 2011
>>>
>>> This is the letter ballot that WG5 agreed to hold on the draft PDTR for
>>> further interoperability of Fortran with C. It has been constructed by
>>> the editor Bill Long following the recent WG5 meeting, see Resolution G7
>>> in N1861. He has documented the changes from N1854 in N1865.
>>>
>>> Please answer the following question "Is N1866 ready for forwarding to SC22
>>> as the PDTR?" in one of these ways.
>>>
>>> 3) No, for the following reasons.
>>>
>>> There appears to be a conflict, or at least some ambiguity, concerning
>>> type parameters.  On one hand, 2.1p2, 6.3p3, and 6.4p5 specify that
>>> TYPE(*) dummy arguments assume their type and type parameters from the
>>> effective argument.  On the other hand, 3.3p2 specifies that an
>>> assumed-type dummy argument shall not correspond to an actual argument
>>> that is of a derived type that has type parameters.  Does the assumption
>>> of type parameters apply only to character length?  This should be made
>>> more explicit.  Are kind type parameters actually a problem?
>>>
>>>
>>
>> Interesting viewpoint, but I'm not convinced there is an actual problem.
>>
>> Both intrinsic (all of them) and derived types (some may) have type
>> parameters.  Derived types with type parameters are excluded by 3.3, but
>> intrinsic types are still allowed.  In the sentence "... and its dynamic
>> type and type parameters are assumed from its effective argument" there
>> is an implied trailer "for effective arguments that are allowed".  We
>> don't usually include qualifying text like that in the standard.
>>
>
> The only intrinsic type that has a length parameter is character.  Kind
> type parameters are not assumed.  The (appearance of an) internal

I hope that is not correct.  Consider an interface, declaration, and 
call that look like this:

interface
      subroutine sub (x) bind(c)
         type(*),dimension(..) :: x
      end subroutine sub
end interface

real(C_double) :: z(10,10)

call sub(z)

and assume that sub is actually written in C.  I hope that the type 
member in the incoming C descriptor is correctly set to CFI_type_double 
and the elem_len member is correctly set.   If the kind type parameter 
of the actual argument is not "assumed" by the type(*) dummy x, this 
simple example will not work.

Sure, it is not an "assumed type parameter"  in the sense of syntax rule 
R401, but the type(*) form has no connection to that syntax.  For 
type(*) the type parameters are "assumed from its effective argument" in 
the ordinary English language sense of "assumed".

Cheers,
Bill


> contradiction would be eliminated if 2.1p2, 6.3p3, and 6.4p5 said that
> the length of an assumed-length character argument is assumed from the
> effective argument, instead of saying, without qualification, that type
> parameters are assumed.
>
> It's not clear why 3.3p2 doesn't allow derived types with kind type
> parameters, since they aren't assumed.
>
>> Cheers,
>> Bill
>>
>>
>>
>>> If there is not actually a problem with type parameters, or the problem is trivially addressed, my vote becomes
>>>
>>> 2) Yes, but I recommend the following changes.
>>>
>>>
>> ...
>>
>>
>>
>

-- 
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