Allow end do loop_variable?

[Beliavsky]

Currently one can write

do_i do i=1,5
do_j: do j=1,5
some code
end do do_j
end do do_i

I use labelled do loops for deeply nested loops for clarity. Instead, it would be convenient to write just

do i=1,5
do j=1,5
some code
end do j
end do i

so that the loop variable can be used to label the end of the loop. This would be more concise, and the compiler would check that the loop label is correct

[steve kargl]

The standard permits

do i = 1, 5
some code
end do ! i

The compiler does not need help in checking for the end of a loop.

--
steve

[Beliavsky]

Yes, but sometimes comments are wrong. With my suggested syntax, the compiler would check that j is the loop variable of the loop being terminated if you write

end do j

[Wilson]

On 10/6/2020 3:46 PM, Beliavsky wrote:
> do i=1,5
> do j=1,5
> some code
> end do j
> end do i

>syntax has advantages.

Out of curiosity, what does the compiler do with:

do i=1,5
do j=1,5
some code

end do i
end do j

Or does the answer depend on the compiler?

LEW

[Robin Vowels]

It does this already.
The labels must match.

[Robin Vowels]

On Wednesday, October 7, 2020 at 11:18:35 AM UTC+11, Wilson wrote:
> On 10/6/2020 3:46 PM, Beliavsky wrote:
> > do i=1,5
> > do j=1,5
> > some code
> > end do j
> > end do i
> >syntax has advantages.
>
> Out of curiosity, what does the compiler do with:
> do i=1,5
> do j=1,5
> some code
> end do i
> end do j

.
It would do the same thing as it does now, when loops overlap.
.

[Beliavsky]

On Tuesday, October 6, 2020 at 8:18:35 PM UTC-4, Wilson wrote:
> On 10/6/2020 3:46 PM, Beliavsky wrote:
> > do i=1,5
> > do j=1,5
> > some code
> > end do j
> > end do i
> >syntax has advantages.
>
> Out of curiosity, what does the compiler do with:
> do i=1,5
> do j=1,5
> some code
> end do i
> end do j

The compiler would reject the code with an appropriate error message.

[Ev. Drikos]

On 06/10/2020 21:34, Beliavsky wrote:
> ...

> I use labelled do loops for deeply nested loops for clarity. Instead, it would be convenient to write just
>
> do i=1,5
> do j=1,5
> some code
> end do j
> end do i
>
> so that the loop variable can be used to label the end of the loop. This would be more concise, and the compiler would check that the loop label is correct
>

The implementation would be fairly simple, if you can persuade the
committee to accept it.

IMHO, this feature would make code cleaner.

[Beliavsky]

There is another forum that discusses new features of Fortran. Could someone remind me what it is?

[Ron Shepard]

When I write pseudocode in publications that describe algorithms, this
is usually the convention I use for loops. I also do this in my actual
code sometimes with comments, but as others have pointed out, sometimes
the comments get out of sync with the loop variable names, in which case
the comments do more harm than good and the compiler cannot detect the
inconsistency. I think it would be a nice addition to the language if
the variables could be added optionally as above so that the compiler
can enforce the intended loop terminations.

$.02 -Ron Shepard

[Thomas Koenig]

Ron Shepard <nos...@nowhere.org> schrieb:

I think most of that can already be accomplished with labeled DO
statements. Something like

i_loop: do i=1,5
j_loop: do j=1,5
some code
end do j_loop
end do i_loop

There, the compiler already enforces that the name of the loop
matches. It does have to be unique, though.

[steve kargl]

Then name the loop! Fortran has supported this for a very long time,
and it is consistent with naming of other language constructs.

K_loop: do k = 1, n
code here
end do K_loop

The "comments can get out of sync" argument does not hold water
with named loops.

Using the index-variable in the END DO statement will never be added
to the Fortran standard as it is redundant with named loops.

--
steve

[Beliavsky]

My suggested syntax is more concise, so perhaps more people would use it.
In Fortran, it is optional to name what is being ended in various statements, such as

end program foo
end function foo
end subroutine foo
end interface foo

so arguably the syntax is consistent with the rest of the language.

[Beliavsky]

On Wednesday, October 7, 2020 at 8:00:10 AM UTC-4, Beliavsky wrote:

> There is another forum that discusses new features of Fortran. Could someone remind me what it is?

I see now that it is https://fortran-lang.discourse.group/ .

[FortranFan]

On Wednesday, October 7, 2020 at 8:00:10 AM UTC-4, Beliavsky wrote:

> ..

> There is another forum that discusses new features of Fortran. Could someone remind me what it is?

https://github.com/j3-fortran/fortran_proposals
https://fortran-lang.discourse.group/

[Ron Shepard]

On 10/7/20 11:55 AM, steve kargl wrote:
[...]

> K_loop: do k = 1, n
> code here
> end do K_loop
>
> The "comments can get out of sync" argument does not hold water
> with named loops.
>
> Using the index-variable in the END DO statement will never be added
> to the Fortran standard as it is redundant with named loops.

Yes, I sometimes do this too, particularly if there in an EXIT somewhere
in the loop, but if you have several do loops that use the index k, then
you are stuck because the labels must be unique. As I said before, it
would be a nice addition to the language, and seemingly a minor one, to
allow the loop index on the ENDDO statement.

A similar thing happened with type statements, right? Originally it was
just END TYPE. Then the language was revised to allow optionally the
type name.

$.02 -Ron Shepard

[steve kargl]

I'm going to go out on a limb here, but I suspect that your compiler
supports one or more integers.

k_loop_1: do k = 1, N
end do k_loop_1

k_loop_2: do k = 1, N
end do k_loop_2

--
steve

[John]

This reminds me of a common practice before ENDDO where when long or complexly nested loops were used it was common to use Innn as the index where nnn matched the numeric label on the CONTINUE. Something like

do i10=1,13
:
do i20=4,10,2
:
20 continue
:
10 continue

so I might like something like
do k: 1,20,2
:
write(*,*)'K=',k
enddo k:

which would be equivalent to

block
integer :: k
do k=1,20,2
:
write(*,*)'K=',k
enddo
endblock

where k would only have scope inside the do-loop, and maybe even allowing k to be altered within the loop would be close to the syntax suggested here with the additional functionality of implicitly specifying the scope of K and allowing a currently disallowed capability of allowing the counter to be altered within the loop, although that might just be a new way of creating an infinite loop it would not be any worse than what can be done now with an infinite loop and a simple variable like
do
k=WHATEVER
if(k.lt.0)exit
enddo

but personally I do not have much problem with the current situation. I have looked at a lot of code using the iNNN syntax in pre-enddo code and for it's time I think it was a good idea.

[steve kargl]

John wrote:

> This reminds me of a common practice before ENDDO where when long or complexly nested loops were used it was common to use Innn as the index where nnn matched the numeric label on the CONTINUE. Something like
>
> do i10=1,13
> :
> do i20=4,10,2
> :
> 20 continue
> :
> 10 continue

This could never have worked unless it was some compiler extension. Pre end-do era
had labeled do-loops, e.g.,

do 20 i20 =1, 13
do 10 i10 =1, 13
...
10 continue
20 continue

Granted, encoding the statement label into the do index makes sense.

> so I might like something like
> do k: 1,20,2
> :
> write(*,*)'K=',k
> enddo k:

This is almost the do-current construct, which can be something like

do concurrent (integer :: k = 1:13)
...
end do

It should be feasible to omit the 'concurrent' portion and give 'k'
local scope to the do-loop.

> which would be equivalent to
>
> block
> integer :: k
> do k=1,20,2
> :
> write(*,*)'K=',k
> enddo
> endblock
>
> where k would only have scope inside the do-loop,

That would be an incompatible change to the Fortran standard. 'k' is in the
scope of the block construct. And, if a programmer does not use 'implicit none'
and 'k' has not been previously declared and the 'integer k' declaration within
the block is omitted, then 'k' escapes to the scope of the construct that
contains the block construct.

--
steve

[Ev. Drikos]

On 09/10/2020 03:27, John wrote:
> This reminds me of a common practice before ENDDO where when long or complexly nested loops were used it was common to use Innn as the index where nnn matched the numeric label on the CONTINUE. Something like

> ...

There is another approach (only if I liked using the C preprocessor :-)


$ gfc -cpp -DI="" -DJ="" do_i-2.f90
$ cat do_i-2.f90
do i=1,5
do j=1,5
r=i*j
end do J
end do I
end

[gah4]

On Tuesday, October 6, 2020 at 12:07:52 PM UTC-7, steve kargl wrote:

(snip)

> The compiler does not need help in checking for the end of a loop.

It is not so unusual to leave out a closing loop statement when making changes.
Compilers are very good at catching this, when the open and close
don't match, they won't match by the end of the program.

C, C++, and Java use { and } for grouping loops longer than one statement.

Many editors have the ability to point to one of { or } and find the matching one.
(As long as there aren't unmatched ones in comments or strings.)

Also, one can do a search for either of { and }, go down the program loop by
loop, check that indenting is appropriate, and that loop variables match.

It isn't quite as easy to match DO and END DO with editors. It might not be
so hard to search with programs like grep, for DO and END DO, though it helps
if people don't use them in other places. (Like in variable names.)

As for C, watch for unmatched ones in comments and strings.

[Thomas Koenig]

gah4 <ga...@u.washington.edu> schrieb:

> It isn't quite as easy to match DO and END DO with editors.

Emacs has a nice feature in its Fortran 90 mode.

You type

foobar: do i=1,10

then type

end

and hit tab, and it will then complete that line into

end do foobar

It will also complete other types of END (function, program, if,
module).

[John]

O

>
> do 20 i20 =1, 13

Been a long time since I made a DO loop with a CONTINUE statement. Yes, the old syntax included the
label , as you surmised. The DO CONCURRENT syntax without the CONCURRENT is appealing in that it would be a simple change to existing syntax but does not provide the labeling of the foot of the loop that was a goal of the new constructs being proposed

[steve kargl]

Of course, the do-concurrent can be named as permitted by the Fortran standard.

loop1: do concurrent (k=1:10)
...
end do loop1

It is quite interesting that people seem to have problems with the method
provided by Fortran standard, and so need to invent a new syntax. If one
uses a named do-loop, then the name must appear in the end-do statement
or it is a syntax error.

--
steve

[Gary Scott]

I wasn't happy with the defined label syntax. I use it only when
absolutely necessary to provide the exit strategy I need without
resorting to gotos. I wish those designing languages had a broad usage
experience with many other languages before they go off and design
something (or to be honest, I wish they had at a minimum, my own
experience with a wide array of other languages).

[steve kargl]

You seem to be suggesting that members of J3 have experience
with no other languages. I suspect you're wrong here. As a logical
extension to your desire that language designers study and adopt
syntax from other languages, I'll simple note that Fortran is one of
the oldest high-level langauges (if not oldest!), why did all the
designers of other languages not adopt Fortran syntax. Certainly,
the K of K&R knew Fortran 66 (and likely what became F77).

--
steve

[Thomas Koenig]

steve kargl <s...@REMOVEtroutmask.apl.washington.edu> schrieb:

> Certainly,
> the K of K&R knew Fortran 66 (and likely what became F77).

Definitely.

He describes in "UNIX: A History and a Memoir" how he wrote
a version of runoff in Fortran 66 to be able to print out his
PhD thesis.

Plus, he implemented Ratfor as a preprocessor to Fortran 66,
which he also used for the first version of "Software Tools".

I have read somewhere that the if/then/else feature of Fortran 77
was implemented because there was prior art with Ratfor.

[spectrum]

On Sunday, October 11, 2020 at 3:33:01 AM UTC+9, steve kargl wrote:
> (...snip...) Fortran is one of the oldest high-level langauges (if not oldest!),

> why did all the designers of other languages not adopt Fortran syntax.
> Certainly, the K of K&R knew Fortran 66 (and likely what became F77).

Hi Steve,

I'm also interested in "how X influenced Y" stories in history,
and according to this article, maybe ALGOL had given
that kind of influence?

John Backus (1924–2007)
https://www.nature.com/articles/446998a

> Story about Ratfor

I guess something like Rat202x might be interesting (as a hobby project :)
(but the meaning of "Rat" is already unclear here... lol)
https://en.wikipedia.org/wiki/Ratfor

[spectrum]

On Wednesday, October 7, 2020 at 3:34:51 AM UTC+9, Beliavsky wrote:
> do j=1,5
> some code
> end do j
> end do i

In my case, I do a very similar thing for a somewhat "big" do-loop
that does not fit in one screen of my terminal (only 40 lines etc), like

do istep = 1, Nsteps
!! blah
!! blah blah
!! (... more code follows ... and the screen goes to a next "page")
enddo !! istep (<-- comment style varies)

# Because Emacs does not do this automatically (via TAB completion),
# I just do it manually atm. It might be possible to modify f90.el by mimicking
# the part of subroutine name completion etc, though...
# https://github.com/jwiegley/emacs-release/blob/master/lisp/progmodes/f90.el

-----
If Fortran might support

do istep = 1, Nsteps
...
enddo istep

(in a way similar to subroutine names), I will probably use it for big do-loops because
it can also check the correspondence automatically (as mentioned above).

FYI, I almost never put the procedure/interface name at the "end" statement,
because it is very confusing to me (visually) that two routine names appear
in very close lines sequentially.

[steve kargl]

spectrum wrote:

> On Sunday, October 11, 2020 at 3:33:01 AM UTC+9, steve kargl wrote:
>> (...snip...) Fortran is one of the oldest high-level langauges (if not oldest!),
>> why did all the designers of other languages not adopt Fortran syntax.
>> Certainly, the K of K&R knew Fortran 66 (and likely what became F77).
>
> Hi Steve,
>
> I'm also interested in "how X influenced Y" stories in history,
> and according to this article, maybe ALGOL had given
> that kind of influence?
>
> John Backus (1924–2007)
> https://www.nature.com/articles/446998a
>

If you're interested in histories of programming language, then
you should probably take sometime to read through

https://en.wikipedia.org/wiki/Brian_Kernighan

Of particular interest might be the article,

The first documented "Hello, world!" program, in Kernighan's
"A Tutorial Introduction to the Language B" (1972)

Note B preceded C.

The article contains 'Fortran' 22 times. There is also this sentence:

All B programs consist of one or more "functions", which are similar
to the functions and subroutines of a Fortran program, or the
procedures of PL/I.

--
steve

[Robin Vowels]

.
Because it was arcane.
That's how PL/I was developed, using some of the ideas
from FORTRAN but not the syntax.

[Robin Vowels]

.
if/then/else has been around well before F77 -- in Algol 58, Algol 60,
and PL/I (1965).

[JCampbell]

On Wednesday, October 7, 2020 at 6:07:52 AM UTC+11, steve kargl wrote:
> Beliavsky wrote:
>
> > Currently one can write
> >
> > do_i do i=1,5
> > do_j: do j=1,5
> > some code
> > end do do_j
> > end do do_i

> >
> > I use labelled do loops for deeply nested loops for clarity. Instead, it would be convenient to write just
> >
> > do i=1,5

> > do j=1,5
> > some code
> > end do j
> > end do i
> >

> > so that the loop variable can be used to label the end of the loop. This would be more concise, and the compiler would check that the loop label is correct

> The standard permits
>
> do i = 1, 5
> some code
> end do ! i

>
> The compiler does not need help in checking for the end of a loop.
>

> --
> steve
I have for a long time agreed with this suggestion.
I often use as steve suggests, but it would have been good if the standard syntax supported the use of the index as a label name and allowing checking of multi loop terminations.
This also identifies the possibility of multiple uses of the same label, outside the scope of each DO, where a similar calculation can be repeated. This can easily occur if there are multiple DO loops for "day", "node" or "equation" (but not within the same loop scope), but if each loop is properly terminated it should be ok.
It is an easy way to document a depth of do's, without trying to reinvent a new label for the same form of the calculation.

[Robin Vowels]

On Monday, October 12, 2020 at 6:59:35 PM UTC+11, JCampbell wrote:
> On Wednesday, October 7, 2020 at 6:07:52 AM UTC+11, steve kargl wrote:
> > Beliavsky wrote:
> >
> > > Currently one can write
> > >
> > > do_i do i=1,5
> > > do_j: do j=1,5
> > > some code
> > > end do do_j
> > > end do do_i
> > >
> > > I use labelled do loops for deeply nested loops for clarity. Instead, it would be convenient to write just
> > >
> > > do i=1,5
> > > do j=1,5
> > > some code
> > > end do j
> > > end do i
> > >
> > > so that the loop variable can be used to label the end of the loop. This would be more concise, and the compiler would check that the loop label is correct
> > The standard permits
> >
> > do i = 1, 5
> > some code
> > end do ! i
> >
> > The compiler does not need help in checking for the end of a loop.

> I have for a long time agreed with this suggestion.
> I often use as steve suggests, but it would have been good if the standard
> syntax supported the use of the index as a label name and allowing checking
> of multi loop terminations.

.
Under this proposal, when a number of loops in the program are of the form
DO J = 1,10 and finish with END DO J,
How do you know which END DO J you are looking at, when the DO J = 1,10
is off the screen?
.
Having multiple END DO J statements in a long program could be
confusing to the reader.

[JCampbell]

Robin,
Although "Having multiple END DO J statements in a long program could be confusing to the reader." it is certainly much less confusing than having multiple END DO statements. It is easy when programming to annotate an END DO with the DO variable, rather than think of multiple labels that do not relate directly to the data constructs.

[Robin Vowels]

.
1. Do you use indenting?
2. END DO statements can have a label.
3. The corresponding DO statement can have that same label.

.
> It is easy when programming to annotate an END DO with the DO variable,
> rather than think of multiple labels that do not relate directly to the data constructs.

.
4. It is also easy to annotate the DO statement with an appropriate name, which can
incorporate the control variable, if required (as has already been
suggested upthread).

[JCampbell]

Compilers do not interpret indenting, so this can often obscure any problems when the layout looks ok.

> 2. END DO statements can have a label.
> 3. The corresponding DO statement can have that same label.
> .
> > It is easy when programming to annotate an END DO with the DO variable,
> > rather than think of multiple labels that do not relate directly to the data constructs.
> .

It would also be an easy alternative to use the DO variable as an alternative for the label, which the compiler could then validate.

> 4. It is also easy to annotate the DO statement with an appropriate name, which can
> incorporate the control variable, if required (as has already been
> suggested upthread).

Robin, do you actually use Fortran ? Or merely compare it to AP1

[Robin Vowels]

.

> Compilers do not interpret indenting, so this can often obscure any
> problems when the layout looks ok.

.
Good reason for writing well-presented code.

.
> > 2. END DO statements can have a label.
> > 3. The corresponding DO statement can have that same label.
> > .
> > > It is easy when programming to annotate an END DO with the DO variable,
> > > rather than think of multiple labels that do not relate directly to the data constructs.
> > .
> It would also be an easy alternative to use the DO variable as an
> alternative for the label, which the compiler could then validate.

.
The compiler can easily validate labels on the DO statement
and in the END DO statement as now.

.
> > 4. It is also easy to annotate the DO statement with an appropriate name, which can
> > incorporate the control variable, if required (as has already been
> > suggested upthread).
.
> Robin, do you actually use Fortran ? Or merely compare it to AP1

.
I have implemented some large projects in Fortran and other other
languages.

[spectrum]

Thanks very much for the info, and I will check more about the "family tree"
of various languages :)

[John]

As a footnote on the "family tree", Lewis Ondis (who was one of the first two people to use Fortran outside of IBM at Bettis Labs )proposed an if/else/endif syntax when they first obtained it from IBM long before there was any official form of Fortran (he said all the books were wrong about who the first one was that ran it and that it was the Operators, as the load of Fortran included a confidence test. When they loaded Fortran onto the system from cards they ran the job that created the compiler and also ran the test case). He continued to advocate for such a syntax up until it was adopted and was frustrated for a very long time that it had emerged in many other languages before being adapted officially by Fortran.