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

[Van Snyder]

On Mon, 2018-12-03 at 18:45 +0000, Bill Long 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.


Ummm, yes.  Exactly.  Did you read the paper at the meeting?  It does
say "the <do-variable> becomes a construct entity."



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


The loop variable is not undefined at the end of the loop.  It's a
construct entity, so it doesn't exist outside the loop.  That was the
point!  I thought this was too obvious to emphasize.  This was also
described in section 2.1.1 of 18-119, 04-155, 08-197, and 08-201.


> 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



I advocated that if one wants local locality for a variable in a DO
CONCURRENT construct, one should use a BLOCK construct.  Somehow, that
was too much work or too confusing or nobody read the paper, or
something.

Which way is it?  Are you just blowing the wind in different directions
at different instants for your own convenience?


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


At the end of DO CONCURRENT, the index variables don't exist.
Therefore, nobody asks what their values are.

Nobody asks about the values of the <ac-do-variable> in
<ac-implied-do-control>, or the  <data-i-do-variable> in
<data-implied-do>.  Nobody would ask about the value of the
<do-variable> in <io-implied-do>.  Nobody advocates that one ought to
put BLOCK constructs around uses of them.


> I think I have to agree with the JoR decision. The benefit vs
> confusion balance favors not adding this feature. 


Should I assume you got to this conclusion by discussions with people
who teach Fortran, or refuse to teach it?  I was an adjuct associate
professor of computer science for seventeen years.  I was chair of the
curriculum committee for five years.  I had many discussions with other
teachers.


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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20181203/c4e31567/attachment.html>