Fortran (in free-form mode) is now the third language I’ve come across
that allows semicolons to terminate statements, but makes them
optional (letting a newline do the job instead).

The other two are JavaScript and Python. JavaScript has the most
complex-seeming rule, but once you understand how it works, being able
to write something like

f(a, b, c)

as

f
(
a,
b,
c
)

(where a, b and c might be quite complex expressions) is quite useful.

Python has I think the most straightforward rule: you need to end a
line with “\” to do explicit continuation, but continuation can be
implicit if there is an unpaired opening parenthesis, bracket or
brace. So complex expressions can be written with minimal clutter:

section_verts = \
[
start + vec(0, - rail_width / 2, 0),
start + vec(0, rail_width / 2, 0),
start + vec(0, - rail_width / 2, rail_thickness * slope_adjust),
start + vec(0, rail_width / 2, rail_thickness * slope_adjust),
]

Free-form Fortran, on the other hand, requires an explicit “&” to
continue a line in all cases:

character(len = 9), dimension(3, 4), parameter :: month_names = &
reshape &
( &
(/ ' January ', ' February', ' March ', ' April ', &
' May ', ' June ', ' July ', ' August ', &
'September', ' October ', ' November', ' December' /), &
(/3, 4/) &
)

Wouldn’t it be useful if it had a smarter, Python-style rule?

Lawrence D'Oliveiro wrote:
> Fortran (in free-form mode) is now the third language I’ve come across
> that allows semicolons to terminate statements, but makes them
> optional (letting a newline do the job instead).
>
> The other two are JavaScript and Python. JavaScript has the most
> complex-seeming rule, but once you understand how it works, being able
> to write something like
>
> f(a, b, c)
>
> as
>
> f
> (
> a,
> b,
> c
> )
>
> (where a, b and c might be quite complex expressions) is quite useful.
>
> Python has I think the most straightforward rule: you need to end a
> line with “\” to do explicit continuation, but continuation can be
> implicit if there is an unpaired opening parenthesis, bracket or
> brace. So complex expressions can be written with minimal clutter:
>
> section_verts = \
> [
> start + vec(0, - rail_width / 2, 0),
> start + vec(0, rail_width / 2, 0),
> start + vec(0, - rail_width / 2, rail_thickness * slope_adjust),
> start + vec(0, rail_width / 2, rail_thickness * slope_adjust),
> ]
>
> Free-form Fortran, on the other hand, requires an explicit “&” to
> continue a line in all cases:
>
> character(len = 9), dimension(3, 4), parameter :: month_names = &
> reshape &
> ( &
> (/ ' January ', ' February', ' March ', ' April ', &
> ' May ', ' June ', ' July ', ' August ', &
> 'September', ' October ', ' November', ' December' /), &
> (/3, 4/) &
> )
>
> Wouldn’t it be useful if it had a smarter, Python-style rule?
>

I don't think posting here is going to have any influence on the people
who define the Fortran standards.

Looking at the JavaScript example. One pair of () brackets is easy to
keep track of, multiple nested brackets (complex expressions) can lead
to mismatched brackets and very confusing / entertaining syntax errors.

I have never used Python but my understanding is that indentation is
important (or critical) there so you have an extra level of clarity
which FF Fortran does not offer.

Handling syntax errors is important, making sure than syntax errors do
not accidentally produce valid syntax (leaving a ")" off in JavaScript,
inserting one a couple of lines further down) is also important. The
people who define Fortran standards care about stuff like that.

On 2/5/2024 9:04 PM, Lawrence D'Oliveiro wrote:
> Fortran (in free-form mode) is now the third language I’ve come across
> that allows semicolons to terminate statements, but makes them
> optional (letting a newline do the job instead).
>

SNIP

> Free-form Fortran, on the other hand, requires an explicit “&” to
> continue a line in all cases:
>
> character(len = 9), dimension(3, 4), parameter :: month_names = &
> reshape &
> ( &
> (/ ' January ', ' February', ' March ', ' April ', &
> ' May ', ' June ', ' July ', ' August ', &
> 'September', ' October ', ' November', ' December' /), &
> (/3, 4/) &
> )
>
> Wouldn’t it be useful if it had a smarter, Python-style rule?

I'm not a fan of this style myself, I would probably alter this to be a
little less verbose and to use longer line lengths. Unfortunately, my
posting setting don't allow long line lengths (easily) for posting here.
So I'd probably use longer lengths than below resulting in only 2
lines. I definitely hate breaking out parentheses on separate lines.
These are argument/parameter/initializer groupings, not code block
separators.

character(9), parameter :: month_names(3,4) = reshape((/'January', &
' February', ' March ', ' April ', ' May ',' June ', &
' July ', ' August ', 'September', ' October ', ' November', &
' December' /), (/3, 4/))

Lawrence D'Oliveiro <ldo@nz.invalid> schrieb:
> Fortran (in free-form mode) is now the third language I’ve come across
> that allows semicolons to terminate statements, but makes them
> optional (letting a newline do the job instead).

Fixed-form Fortran also allows a semicolon.

[...]

> Python has I think the most straightforward rule: you need to end a
> line with “\” to do explicit continuation, but continuation can be
> implicit if there is an unpaired opening parenthesis, bracket or
> brace.

That sounds like a recipe for errors, if you ask me.

But then again, I don't like Python's reliance on indentation
as marking control structure, either, so maybe this is just
not a language for me.

>So complex expressions can be written with minimal clutter:
>
> section_verts = \
> [
> start + vec(0, - rail_width / 2, 0),
> start + vec(0, rail_width / 2, 0),
> start + vec(0, - rail_width / 2, rail_thickness * slope_adjust),
> start + vec(0, rail_width / 2, rail_thickness * slope_adjust),
> ]
>
> Free-form Fortran, on the other hand, requires an explicit “&” to
> continue a line in all cases:
>
> character(len = 9), dimension(3, 4), parameter :: month_names = &
> reshape &
> ( &
> (/ ' January ', ' February', ' March ', ' April ', &
> ' May ', ' June ', ' July ', ' August ', &
> 'September', ' October ', ' November', ' December' /), &
> (/3, 4/) &
> )
>
> Wouldn’t it be useful if it had a smarter, Python-style rule?

I don't think it is particularly useful to mix parentheses and line
continuation.

And the chances of the committee changing that now, 33 years after
free-form Fortran came out, infinitesimal.

On Tue, 6 Feb 2024 10:58:20 -0600, Gary Scott wrote:

> So I'd probably use longer lengths than below ...

In the only one of the three languages that imposes line-length limits?

Now *that’s* living dangerously ...

On Tue, 6 Feb 2024 19:00:04 -0000 (UTC), Thomas Koenig wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> schrieb:
>
>> Python has I think the most straightforward rule: you need to end a
>> line with “\” to do explicit continuation, but continuation can be
>> implicit if there is an unpaired opening parenthesis, bracket or brace.
>
> That sounds like a recipe for errors, if you ask me.

Combine that with proper indentation, to use a two-dimensional layout
on the page/screen, and that can be helpful for making clear the
structure of an expression. Example: parsing a timezone-offset part of
a PDF date/time entry:

if tzdelta != None and tzdelta != "Z" :
tzdelta = re.fullmatch(r"(.)(\d+)(?:\'(\d+))?", tzdelta).groups()
tzdelta = \
(
(
int(tzdelta[1]) * 60
+
(lambda : 0, lambda : int(tzdelta[2]))[tzdelta[2] != None]()
)
*
60
*
(1, -1)[tzdelta[0] == "-"]
)
else :
tzdelta = 0
#end if

On Tue, 6 Feb 2024 10:14:20 +0100, Andrew wrote:

> Looking at the JavaScript example. One pair of () brackets is easy to
> keep track of, multiple nested brackets (complex expressions) can lead
> to mismatched brackets and very confusing / entertaining syntax errors.

One technique I have found for minimizing errors is to always enter
the closing bracketing symbol immediately after the opener, then start
inserting the stuff that does between. This reduces the chance of
bracketing mismatches.

Here’s a more complex example: using indentation in a two-dimensional
layout to make clearer the structure of the expression:

const SECONDS_PER_MINUTE = 60
const SECONDS_PER_HOUR = 3600

document.getElementById("content").innerHTML =
Array.from
(
function*() /* generate entries */
{
for (let i = 0; i <= 32; ++i)
{
yield i * SECONDS_PER_HOUR / 4
} /*for*/
}(),
function(t) /* format entries as hh:mm */
{
const hours = Math.floor(t / SECONDS_PER_HOUR)
const minutes = Math.floor((t - hours * SECONDS_PER_HOUR) / SECONDS_PER_MINUTE)
return "" + hours + ":" + (minutes < 10 ? "0" : "") + minutes
}
).reduce
(
(sofar, elt) => /* join entries into a single string */
sofar + (sofar != "" ? ", " : "") + elt,
""
)

On Tue, 6 Feb 2024 19:00:04 -0000 (UTC), Thomas Koenig wrote:

> And the chances of the committee changing that now, 33 years after
> free-form Fortran came out, infinitesimal.

Removing a restriction is a backward-compatible change.

On 2/6/2024 1:56 PM, Lawrence D'Oliveiro wrote:
> On Tue, 6 Feb 2024 10:58:20 -0600, Gary Scott wrote:
>
>> So I'd probably use longer lengths than below ...
>
> In the only one of the three languages that imposes line-length limits?
>
> Now *that’s* living dangerously ...
Not really, its a quite long limit. And a warning at compile time is
issued if by some weird chance I hit the limit in the standard (132)
(and most compilers have a much longer limit still (Intel 2048)).

On Tue, 06 Feb 2024 15:34:25 -0600, Gary Scott wrote:

> On 2/6/2024 1:56 PM, Lawrence D'Oliveiro wrote:
>> On Tue, 6 Feb 2024 10:58:20 -0600, Gary Scott wrote:
>>
>>> So I'd probably use longer lengths than below ...
>>
>> In the only one of the three languages that imposes line-length limits?
>>
>> Now *that’s* living dangerously ...
> Not really, its a quite long limit. And a warning at compile time is
> issued if by some weird chance I hit the limit in the standard (132)
> (and most compilers have a much longer limit still (Intel 2048)).

The Fortran 2023 standard has increased the limit.

6.3.2.1 Free form line length
...
A line shall contain at most ten thousand characters.

--
steve

On 2/6/2024 6:48 PM, Steven G. Kargl wrote:
> On Tue, 06 Feb 2024 15:34:25 -0600, Gary Scott wrote:
>
>> On 2/6/2024 1:56 PM, Lawrence D'Oliveiro wrote:
>>> On Tue, 6 Feb 2024 10:58:20 -0600, Gary Scott wrote:
>>>
>>>> So I'd probably use longer lengths than below ...
>>>
>>> In the only one of the three languages that imposes line-length limits?
>>>
>>> Now *that’s* living dangerously ...
>> Not really, its a quite long limit. And a warning at compile time is
>> issued if by some weird chance I hit the limit in the standard (132)
>> (and most compilers have a much longer limit still (Intel 2048)).
>
> The Fortran 2023 standard has increased the limit.
>
> 6.3.2.1 Free form line length
> ...
> A line shall contain at most ten thousand characters.
>
I was thinking that, but didn't find it in a quick search. Not sure
what compilers support it yet though.

Le 06/02/2024 à 20:00, Thomas Koenig a écrit :
>
> And the chances of the committee changing that now, 33 years after
> free-form Fortran came out, infinitesimal.

The committee is very reluctant with backward incompatible changes, but
this one would be backward compatible.

Le 06/02/2024 à 04:04, Lawrence D'Oliveiro a écrit :

> Python has I think the most straightforward rule: you need to end a
> line with “\” to do explicit continuation, but continuation can be
> implicit if there is an unpaired opening parenthesis, bracket or
> brace. So complex expressions can be written with minimal clutter:
>
> section_verts = \
> [
> start + vec(0, - rail_width / 2, 0),
> start + vec(0, rail_width / 2, 0),
> start + vec(0, - rail_width / 2, rail_thickness * slope_adjust),
> start + vec(0, rail_width / 2, rail_thickness * slope_adjust),
> ]
>
> Free-form Fortran, on the other hand, requires an explicit “&” to
> continue a line in all cases:
>
> character(len = 9), dimension(3, 4), parameter :: month_names = &
> reshape &
> ( &
> (/ ' January ', ' February', ' March ', ' April ', &
> ' May ', ' June ', ' July ', ' August ', &
> 'September', ' October ', ' November', ' December' /), &
> (/3, 4/) &
> )
>
> Wouldn’t it be useful if it had a smarter, Python-style rule?

This topic has been discussed here:
https://github.com/j3-fortran/fortran_proposals/issues/130

It converged to something similar to the Python way. You can "vote" in the
discussion to support the suggestion.

On 06.02.2024 04.04, Lawrence D'Oliveiro wrote:
> Fortran (in free-form mode) is now the third language I’ve come across
> that allows semicolons to terminate statements, but makes them
> optional (letting a newline do the job instead).
[...]

Pascal and Algol demand semicolons at the end of statements.
--
Dieter Britz

On Fri, 9 Feb 2024 15:49:37 +0100, db wrote:

> Pascal and Algol demand semicolons at the end of statements.

No they don’t. In those languages, semicolons are statement separators,
not statement terminators.

Pascal requires them at the end of declarations, of everything except the
main program, which ends with a full stop.

On 2/9/2024 3:26 PM, Lawrence D'Oliveiro wrote:
> On Fri, 9 Feb 2024 15:49:37 +0100, db wrote:
>
>> Pascal and Algol demand semicolons at the end of statements.
>
> No they don’t. In those languages, semicolons are statement separators,
> not statement terminators.
>
> Pascal requires them at the end of declarations, of everything except the
> main program, which ends with a full stop.
They're also statement separators in Fortran.

On Fri, 9 Feb 2024 21:00:48 -0600, Gary Scott wrote:

> They're also statement separators in Fortran.

Section 6.3.2.5 of the Fortran 2018 spec, second paragraph:

A statement may alternatively be terminated by a “;” character
that appears other than in a character context or in a comment.
The “;” is not part of the statement. After a “;” terminator,
another statement may appear on the same line, or begin on that
line and be continued. A sequence consisting only of zero or more
blanks and one or more “;” terminators, in any order, is
equivalent to a single “;” terminator.

Note it says “terminator”, not “separator”.

On 2/9/2024 10:51 PM, Lawrence D'Oliveiro wrote:
> On Fri, 9 Feb 2024 21:00:48 -0600, Gary Scott wrote:
>
>> They're also statement separators in Fortran.
>
> Section 6.3.2.5 of the Fortran 2018 spec, second paragraph:
>
> A statement may alternatively be terminated by a “;” character
> that appears other than in a character context or in a comment.
> The “;” is not part of the statement. After a “;” terminator,
> another statement may appear on the same line, or begin on that
> line and be continued. A sequence consisting only of zero or more
> blanks and one or more “;” terminators, in any order, is
> equivalent to a single “;” terminator.
>
> Note it says “terminator”, not “separator”.
It terminates the statement, not the line. It is common to place
multiple statements on one line with ; as the separator between the
multiple terminated statements on one line.

On Sat, 10 Feb 2024 08:17:04 -0600, Gary Scott wrote:

> On 2/9/2024 10:51 PM, Lawrence D'Oliveiro wrote:
>
>> On Fri, 9 Feb 2024 21:00:48 -0600, Gary Scott wrote:
>>
>>> They're also statement separators in Fortran.
>>
>> Section 6.3.2.5 of the Fortran 2018 spec, second paragraph:
>>
>> A statement may alternatively be terminated by a “;” character
>> that appears other than in a character context or in a comment.
>> The “;” is not part of the statement. After a “;” terminator,
>> another statement may appear on the same line, or begin on that
>> line and be continued. A sequence consisting only of zero or more
>> blanks and one or more “;” terminators, in any order, is
>> equivalent to a single “;” terminator.
>>
>> Note it says “terminator”, not “separator”.
>
> It terminates the statement ...

Well, you did say “separators” of statements, not “terminators”, did you
not?

On Sat, 10 Feb 2024 21:21:09 +0000, Lawrence D'Oliveiro wrote:

> On Sat, 10 Feb 2024 08:17:04 -0600, Gary Scott wrote:
>
>> On 2/9/2024 10:51 PM, Lawrence D'Oliveiro wrote:
>>
>>> On Fri, 9 Feb 2024 21:00:48 -0600, Gary Scott wrote:
>>>
>>>> They're also statement separators in Fortran.
>>>
>>> Section 6.3.2.5 of the Fortran 2018 spec, second paragraph:
>>>
>>> A statement may alternatively be terminated by a “;” character
>>> that appears other than in a character context or in a comment.
>>> The “;” is not part of the statement. After a “;” terminator,
>>> another statement may appear on the same line, or begin on that
>>> line and be continued. A sequence consisting only of zero or more
>>> blanks and one or more “;” terminators, in any order, is
>>> equivalent to a single “;” terminator.
>>>
>>> Note it says “terminator”, not “separator”.
>>
>> It terminates the statement ...
>
> Well, you did say “separators” of statements, not “terminators”, did you
> not?

Well, the Fortran 2023 standard also contains

4.1.4 Syntax conventions and characteristics

Any syntactic class name ending in "-stmt" follows the source
form statement rules: it shall be delimited by end-of-line or
semicolon, ...

so, I suppose one could call it a delimiter. Who cares what its
called as long as one knows how to use it? Given the volume of
your posts in c.l.c and c.l.f, I doubt you care.

--
steve

On Sat, 10 Feb 2024 23:35:57 -0000 (UTC), Steven G. Kargl wrote:

>On Sat, 10 Feb 2024 04:51:38 -0000 (UTC), Lawrence D'Oliveiro wrote:
>
>> On Fri, 9 Feb 2024 21:00:48 -0600, Gary Scott wrote:
>>
>>> They're also statement separators in Fortran.
>>
>> Section 6.3.2.5 of the Fortran 2018 spec, second paragraph:
>>
>> A statement may alternatively be terminated by a “;” character that
>> appears other than in a character context or in a comment.
>> The “;” is not part of the statement. After a “;” terminator,
>> another statement may appear on the same line, or begin on that
line
>> and be continued. A sequence consisting only of zero or more blanks
>> and one or more “;” terminators, in any order, is equivalent to a
>> single “;” terminator.
>>
>> Note it says “terminator”, not “separator”.
>
> Well, the Fortran 2023 standard also contains
>
> 4.1.4 Syntax conventions and characteristics
>
> Any syntactic class name ending in "-stmt" follows the source form
> statement rules: it shall be delimited by end-of-line or semicolon,
> ...
>
> so, I suppose one could call it a delimiter.

Given that a “delimiter” could be either a “terminator” or a
“separator”, that doesn’t seem very helpful.

On 2/10/2024 3:21 PM, Lawrence D'Oliveiro wrote:
> On Sat, 10 Feb 2024 08:17:04 -0600, Gary Scott wrote:
>
>> On 2/9/2024 10:51 PM, Lawrence D'Oliveiro wrote:
>>
>>> On Fri, 9 Feb 2024 21:00:48 -0600, Gary Scott wrote:
>>>
>>>> They're also statement separators in Fortran.
>>>
>>> Section 6.3.2.5 of the Fortran 2018 spec, second paragraph:
>>>
>>> A statement may alternatively be terminated by a “;” character
>>> that appears other than in a character context or in a comment.
>>> The “;” is not part of the statement. After a “;” terminator,
>>> another statement may appear on the same line, or begin on that
>>> line and be continued. A sequence consisting only of zero or more
>>> blanks and one or more “;” terminators, in any order, is
>>> equivalent to a single “;” terminator.
>>>
>>> Note it says “terminator”, not “separator”.
>>
>> It terminates the statement ...
>
> Well, you did say “separators” of statements, not “terminators”, did you
> not?
Yes, it does serve that purpose. It is proper use of english. The
clarification is that it does not terminate the line. Some of the
discussion appeared to have potentially confused termination of a
statement from termination of a line. When multiple statements occur on
the same line, the term statement "separator" is completely appropriate
and correct. That is the purpose it serves conceptually.

On Sat, 10 Feb 2024 19:31:02 -0600, Gary Scott wrote:

> Some of the discussion appeared to have potentially confused termination
> of a statement from termination of a line.

Really? Where? (Hint: look at the subject line.)

On 2/10/2024 7:43 PM, Lawrence D'Oliveiro wrote:
> On Sat, 10 Feb 2024 19:31:02 -0600, Gary Scott wrote:
>
>> Some of the discussion appeared to have potentially confused termination
>> of a statement from termination of a line.
>
> Really? Where? (Hint: look at the subject line.)
Exactly

On Sat, 10 Feb 2024 20:04:36 -0600, Gary Scott wrote:

> On 2/10/2024 7:43 PM, Lawrence D'Oliveiro wrote:
>
>> On Sat, 10 Feb 2024 19:31:02 -0600, Gary Scott wrote:
>>
>>> Some of the discussion appeared to have potentially confused
>>> termination of a statement from termination of a line.
>>
>> Really? Where? (Hint: look at the subject line.)
>
> Exactly

Who introduced this “confusion” into the discussion?

Not me.