Cancelled: Fortran Monthly Call: June 2023

Dear all,

It’s again time to organise our next monthly call which will be in the week of June 26-June 30; please see the following doodle poll to mark your availability:

Doodle: Fortran Monthly Call: June 2023

The final time slot will be selected and announced on the evening (European time) of June 21, please complete the poll before then .

If there are specific topics or issues you would like to raise, even if you are unable to attend the call, please post them in the thread here.

As usual, we will record this call and make it available online.

All the best,


Our next monthly call will be on Tuesday, June 27 at 15 UTC.

8:00 - 9:00 PST (California)
16:00 - 17:00 BST (London)
17:00 - 18:00 CET (Amsterdam)

As previously, the meeting will be recorded for those who cannot attend.
Don’t hesitate to propose your items below.


Tuesday, June 27? :thinking:

You are right, @gak. I will change it. Thank you for noticing it.

@jeremie.vandenplas, unfortunately, I will not be able to join, but two things:


Is there a preprint for the paper?

Not yet, but I can send you my PDF file.

1 Like

Shall I send my email in DM?

Thank you @Arjen.

Any other topics for the meeting?

Please do.

1 Like

Unfortunately, I won’t be able to make it today either.

No, not at the moment.

I cancel this Fortran monthly call as there is no item at the agenda.

However, I would like to highlight the following update from @Arjen :


I have sent a DM, please check.

I think it would be nice to have a collection of these for reference.

One that I happened to look at is the description of f66 do loops. F66 do loops were not directly or specifically required to execute once, rather the range parameters were restricted so that a single pass was always executed for conforming code. The one-trip execution feature followed indirectly from these constraints. The loop in the example code

    do i = 1,0
        write(*,*) 'FORTRAN 66: ', i

    write(*,*) 'Current value of i:', i

Would have been illegal for five reasons. 1) the do statement would have required an integer statement label; the unlabeled do with enddo was not introduced until f90. 2) the termination value m2 is zero. In f66, the m1, m2, and m3 values were all required to be greater than zero. 3) the m1 value must be less than or equal to the m2 value, a constraint on the programmer that is violated in this example. 4) the enddo statement did not exist in f66, it would have been a labeled continue statement. 5) upon execution of the loop, the loop control variable i is undefined, so the final write statement is referencing an undefined integer.

Many compilers would not diagnose and detect violations to the m1, m2, m3 constraints, so they would execute the loop with a single pass. But that was not required or specified by the standard, the standard simply stated the requirements which were violated by the programmers in these cases.

Of course, the write statements also violate f66 in other ways. 1) Character constants did not exist until f77. 2) List-directed i/o did not exist until f77. 3) The use of * to specify the default output logical unit was not defined until f77.

@RonShepard, thanks for this detailed explanation. I will adapt the text. By thew way, I just saw another use of ENTRY that might be a useful addition.

I am not sure if the document as it is now should grow into a catalogue or a bestiary of such old-fashioned idioms, but the examples subdirectory is patient enough …

1 Like

Hi @Arjen , I am interested in reading your paper on the Mathematics of Arrays in combination with Fortran , can you please send me the paper on . Thanks