[J3] Consideration of Paper 18-242 at Meeting 218 (Was: 18-242)

[Clune, Thomas L. (GSFC-6101)]

Thinking a bit further,  I now want to retract my statement.  If the only concern is regarding shadowing external entities with the same-spelling, I am happy with the proposed feature.    

But I expect that there are deeper issues around the actual wording for the existing DO statement that might be very difficult to rewrite without breaking things.

> On Dec 3, 2018, at 3:10 PM, Clune, Thomas L. (GSFC-6101) via J3 <j3 at mailman.j3-fortran.org> wrote:
> 
> Bill,
> 
> Thanks.   I’d not looked closely and was not certain that I understood what the concern was.   Your example makes it very clear.    
> 
> It is unfortunate - I personally would gladly give up backward compatibility for this, but fully accept why that’s not a good idea in the broader picture.
> 
> Cheers,
> 
> - Tom
> 
> 
>> On Dec 3, 2018, at 1:45 PM, Bill Long via J3 <j3 at mailman.j3-fortran.org> wrote:
>> 
>> 
>>> On Dec 1, 2018, at 2:29 PM, Van Snyder via J3 <j3 at mailman.j3-fortran.org> wrote:
>>> 
>>> 
>>> A loop-control declared in the statement would be a construct entity.
>>> That's the point!  It's not an accidental defect.
>> 
>> But the do-variable in an ordinary DO look is NOT a construct entity. The DO semantics depend on this.   I was not part of the JoR discussion, but it seems you are really proposing a whole new, separate form of DO.   For example:
>> 
>> integer(4) :: i
>> 
>> do integer(8) :: i = n,m
>>  if (a(i) < 0) exit
>> end do
>> 
>> call histo(i)  ! Corresponding dummy variable to i  is integer(4)
>> 
>> If the integer(8) :: is removed, then this is an ordinary loop.  If the 3rd iteration exits, the argument to histo has the value n+2 (assuming m > n+2), and has kind 4, which is what histo is expecting.  With the integer(8)::, if I understand your email description, the value if i is undefined at the call to histo.    If you really want this behavior, then write
>> 
>> block
>> integer(8) :: i
>> do i = n,m
>> if (a(i) < 0) exit
>> end do
>> end block
>> 
>> At the end block, it is at least obvious to the programmer that the i declared in the block cannot be used.  At least this version does not violate the principle of least surprise. 
>> 
>> I think I have to agree with the JoR decision.  The benefit vs confusion balance favors not adding this feature. 
>> 
>> Cheers,
>> Bill
>> 
>> 
>> 
>> Bill Long                                                                       longb at cray.com
>> Principal Engineer, Fortran Technical Support &   voice:  651-605-9024
>> Bioinformatics Software Development                      fax:  651-605-9143
>> Cray Inc./ 2131 Lindau Lane/  Suite 1000/  Bloomington, MN  55425
>> 
>> 
>