[J3] (SC22WG5.6223) J3 Fortran interp letter ballot #36

[Bill Long]

> On Jun 4, 2020, at 3:07 PM, Van Snyder <van.snyder at sbcglobal.net> wrote:
> 
> On Thu, 2020-06-04 at 04:05 +0000, Bill Long via J3 wrote:
>> HI Van,
>> 
>> 
>>> On Jun 3, 2020, at 12:35 PM, Van Snyder via J3 <
>>> j3 at mailman.j3-fortran.org> wrote:
>>> 
>>> The following Fortran interpretations are being balloted:
>>> 
>>> Yes  No   Number    Title
>>> 
>>> -C-  ---  F18/015  Example in C.6.8 is wrong
>> 
>> Interesting historical note for the Comment.  But I don’t see how
>> that connects with “Example in C.6.8 is wrong”.  The (replacement)
>> Example is required to conform to the standard.  Does the new code
>> have non-conforming parts?  Or is the logic flawed so that the code
>> does not achieve the intended purpose?    Could you be more specific
>> in the Comment on what exactly is wrong with the new code?   If there
>> is an actual defect, we want to get it fixed in this ballot.  
> 
> Comment belongs to F18/016. Sorry for the confusion.

Ah, that makes more sense. Thanks for the reply.

You might want  to post a “replacement” ballot with the repair, just to avoid confusion. 

Cheers,
Bill

> 
>> 
>>> I opposed the no-host-association semantics for interface bodies in
>>> 1986. My reasoning was that the prohibition makes it impossible to
>>> write an interface body for a dummy procedure that has a derived-
>>> type
>>> argument if the type is defined in the same scoping unit. It didn't
>>> make sense to me. I still don't understand what purpose it served.
>>> I
>>> don't remember the precise details of the discussion, and the
>>> Computer
>>> History Museum now has my correspondence with X3J3 from that time
>>> so I
>>> can't look it up.
>>> 
>>> -Y-  ---  F18/016  Host association changes in Fortran 2018
>>> -Y-  ---  F18/017  Final subroutine invocation order
>>> -C-  ---  F18/018  Public namelist and private variable
>>> 
>>> I disagree with A1: C8105 should exist. PRIVATE prevents access by
>>> use
>>> association, of an identifier. The NAMELIST statement does not
>>> provide
>>> access to any other scoping unit of a group object name. The name
>>> remains private. But as A1 remarks, whether C8105 continues to
>>> exist is
>>> an issue for a future standard.
>>> 
>>> 
>> 
>> Bill
>> Long                                                                 
>>      longb at cray.com
>> Principal Engineer, Fortran Technical Support &   voice:  651-605-
>> 9024
>> Bioinformatics Software Development                      fax:  651-
>> 605-9143
>> Cray, a Hewlett Packard Enterprise company/ 2131 Lindau Lane/  Suite
>> 1000/  Bloomington, MN  55425
>> 
>> 
>> 
> 

Bill Long                                                                       longb at cray.com
Principal Engineer, Fortran Technical Support &   voice:  651-605-9024
Bioinformatics Software Development                      fax:  651-605-9143
Cray, a Hewlett Packard Enterprise company/ 2131 Lindau Lane/  Suite 1000/  Bloomington, MN  55425