From Newsgroup: comp.lang.fortran

From https://gcc.gnu.org/gcc-16/changes.html :

- Coarrays using native shared memory mulithreading on single
node machines and handling Fortran 2018's TEAM feature.

- Fortran 2003: Parameterized Derived Types support is
improved. Handling of LEN parameters works but still requires
a future change of representation (see PR82649).

- Fortran 2018: Support the extensions to the IMPORT statement,
the REDUCE intrinsic and the new GENERIC statement.

- The Fortran 2023 additions to the trigonometric functions are
now supported (such as the sinpi intrinsic).

- Fortran 2023: The split intrinsic subroutine is now supported
and c_f_pointer now accepts an optional lower bound as a argument.

- The -fexternal-blas64 option has been added to call external BLAS
routines with 64-bit integer arguments for MATMUL. This option
is only valid for 64-bit systems and when -ffrontend-optimize is
in effect.
--
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.fortran

On Fri, 1 May 2026 10:30:31 -0000 (UTC), Thomas Koenig wrote:

From https://gcc.gnu.org/gcc-16/changes.html :

- Coarrays using native shared memory mulithreading on single
node machines and handling Fortran 2018's TEAM feature.

- Fortran 2003: Parameterized Derived Types support is
improved. Handling of LEN parameters works but still requires
a future change of representation (see PR82649).

- Fortran 2018: Support the extensions to the IMPORT statement,
the REDUCE intrinsic and the new GENERIC statement.

- The Fortran 2023 additions to the trigonometric functions are
now supported (such as the sinpi intrinsic).

- Fortran 2023: The split intrinsic subroutine is now supported
and c_f_pointer now accepts an optional lower bound as a argument.

- The -fexternal-blas64 option has been added to call external BLAS
routines with 64-bit integer arguments for MATMUL. This option
is only valid for 64-bit systems and when -ffrontend-optimize is
in effect.

In addition to those listed by Thomas, gfortran 16.1
also supports the new F2023 conditional expression
such as

x = (y > 0 ? log(y) : some_error_fcn(x))

Here, log(y) is evaluated iff the condition is
true; otherwise, the other branch is evaluated.
--
steve
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.fortran

On Fri, 1 May 2026 19:31:21 -0000 (UTC), Steven G. Kargl wrote:

... gfortran 16.1 also supports the new F2023 conditional expression
such as

x = (y > 0 ? log(y) : some_error_fcn(x))

Doing it exactly the same way as C (which introduced this syntax) and
just about every other language which adopted the feature afterwards
... except Python.

By the way, do you need the parentheses around the expression?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.fortran

On Fri, 1 May 2026 22:34:42 -0000 (UTC), Lawrence D’Oliveiro wrote:

On Fri, 1 May 2026 19:31:21 -0000 (UTC), Steven G. Kargl wrote:

... gfortran 16.1 also supports the new F2023 conditional expression
such as

x = (y > 0 ? log(y) : some_error_fcn(x))

Doing it exactly the same way as C (which introduced this syntax) and
just about every other language which adopted the feature afterwards
... except Python.

1) Why re-invent the wheel in language design?

2) It is not exactly the same as C. You can
read the working draft of the Fortran standard
to learn more. One can use a conditional
expression as an actual argument to a subprogram
with an optional dummy argument.

call foo((y > 0 ? y : .nil.))

If the condition is true, you have

call foo(y)

if it is false you have

call foo()

By the way, do you need the parentheses around the expression?

Yes, you do.
--
steve

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.fortran

On Sat, 2 May 2026 01:39:14 -0000 (UTC), Steven G. Kargl wrote:

On Fri, 1 May 2026 22:34:42 -0000 (UTC), Lawrence D’Oliveiro wrote:

Doing it exactly the same way as C (which introduced this syntax)
and just about every other language which adopted the feature
afterwards ... except Python.

1) Why re-invent the wheel in language design?

Why indeed. I consider the Python way to be one of the few really bad
mistakes in its language design.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.fortran

Lawrence D’Oliveiro wrote:

On Fri, 1 May 2026 19:31:21 -0000 (UTC), Steven G. Kargl wrote:

... gfortran 16.1 also supports the new F2023 conditional expression
such as

x = (y > 0 ? log(y) : some_error_fcn(x))

Doing it exactly the same way as C (which introduced this syntax) and
just about every other language which adopted the feature afterwards
... except Python.

By the way, do you need the parentheses around the expression?

I first encountered that syntax in Algol68, this was around 1976.
There it would have been
x := (y > 0 | log (y) | some_error_fcn (x)) ;

- I can't remember if underscore is a permitted character in a variable
or a function name.
- The semicolon at the end is only required if another statement follows.
The first edition of my Algol68 manual was published in 1972 so I think
we can assume C got it from Algol68 (or they both got it from some other language).
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.fortran

On Sat, 2 May 2026 11:57:05 +0200, R Daneel Olivaw wrote:

Lawrence D’Oliveiro wrote:

On Fri, 1 May 2026 19:31:21 -0000 (UTC), Steven G. Kargl wrote:

... gfortran 16.1 also supports the new F2023 conditional expression
such as

x = (y > 0 ? log(y) : some_error_fcn(x))

Doing it exactly the same way as C (which introduced this syntax) and
just about every other language which adopted the feature afterwards
... except Python.

By the way, do you need the parentheses around the expression?

I first encountered that syntax in Algol68, this was around 1976.
There it would have been
x := (y > 0 | log (y) | some_error_fcn (x)) ;

- I can't remember if underscore is a permitted character in a variable
or a function name.
- The semicolon at the end is only required if another statement follows.
The first edition of my Algol68 manual was published in 1972 so I think
we can assume C got it from Algol68 (or they both got it from some other language).

During the discussion of the syntax, J3 (standardization committee)
considered a few different syntax. They, of course, converged on
what is now in the Fortran standard. I haven't tried to verify,
but rather infer, that at least one committee member is/was active
in the algol standardization process. For those interested, they
can go to the J3 Fortran website and look at the documents from
2020-2022 to see the evolution of conditional expressions.

I forgot to mention an important aspect of a conditional expression,
and that is short-circuiting can occur. Consider,

if (a > b .and. c > foo(a)) then

Here, the Fortran standard does not specify the order of evaluation
for a > b and c > foo(a). In addition, both operands of .and. will
be evaluated. If foo(a) has a side-effect, an unfortuante thing
may occur. (Yes, a function with a side-effct is evil). Now, with
conditional expressions,

(a > b .and. c > foo(a) ? LFT : RGT)

it is evaluated left-to-right. If a > b is false, c > foo(a) is
not evaluated and RGT is selected.
--
steve



--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.fortran

On Sat, 2 May 2026 18:49:39 -0000 (UTC), Steven G. Kargl wrote:

(Yes, a function with a side-effct is evil).

Not necessarily. There are these things called “memo-functions”, which cache computed results so they can save redoing the computation if
they are given the same set of args later.

Updating the cache is a side-effect, which speeds up execution. Is
that “evil”? I don’t think so.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.fortran

On Sat, 2 May 2026 18:49:39 -0000 (UTC), Steven G. Kargl wrote:

if (a > b .and. c > foo(a)) then

Here, the Fortran standard does not specify the order of evaluation
for a > b and c > foo(a). In addition, both operands of .and. will
be evaluated.

Somehow I don’t think they will. Otherwise GNU Fortran would not do short-circuit evaluation when any significant level of optimization is
turned on.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.fortran

On Sat, 2 May 2026 23:19:50 -0000 (UTC), Lawrence D’Oliveiro wrote:

On Sat, 2 May 2026 18:49:39 -0000 (UTC), Steven G. Kargl wrote:

if (a > b .and. c > foo(a)) then

Here, the Fortran standard does not specify the order of evaluation
for a > b and c > foo(a). In addition, both operands of .and. will
be evaluated.

Somehow I don’t think they will. Otherwise GNU Fortran would not do short-circuit evaluation when any significant level of optimization is
turned on.

Yeah, gfortran has made a processor-dependent choice
to evaluate expressions left-to-right. That's not
required by the Fortran standard *except for conditional
expressions*. In

if (a > b .and. c > foo(a)) then

a Fortran processor, for whatever reason it chooses, can
evaluate the above in a left-to-right after re-arranging
the expression to

if (c > foo(a) .and a > b) then

10.1.5.4.2 Evaluation of logical intrinsic operations

Once the interpretation of a logical intrinsic operation is
established, the processor may evaluate any other expression
that is logically equivalent, provided that the integrity of
parentheses in any expression is not violated.

Two expressions of type logical are logically equivalent if
their values are equal for all possible values of their
primaries.

If foo(a) has a side-effect for a < b, you may end up with a
difficult debugging session. This is why some recommend to
write

if (a > b) then
if (c > foo(a)) then
...
end if
end if

10.1.2.3 Conditional expressions

A conditional expression is a primary that selectively evaluates
a chosen subexpression.

R1002 conditional-expr is ( scalar-logical-expr ? expr [: ] : expr )

I've abbreviated R1002 (you can look it up). [: ] means that R1002
can be recursively applied.

10.1.4 Evaluation of operations
...
Evaluation of a conditional-expr evaluates each scalar-logical-expr
in order, until the value of a scalar-logical-expr is true, or there
are no more scalar-logical-exprs. If the value of a scalar-logical-expr
is true, its subsequent expr is chosen; otherwise, the last expr of
the conditional-expr is chosen. The chosen expr is evaluated, and its
value is the value of the conditional expression.
--
steve
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.fortran

On Sat, 2 May 2026 23:17:51 -0000 (UTC), Lawrence D’Oliveiro wrote:

On Sat, 2 May 2026 18:49:39 -0000 (UTC), Steven G. Kargl wrote:

(Yes, a function with a side-effct is evil).

Not necessarily. There are these things called “memo-functions”, which cache computed results so they can save redoing the computation if
they are given the same set of args later.

Updating the cache is a side-effect, which speeds up execution. Is
that “evil”? I don’t think so.

A better example is a PRNG function. Fortran does not
have an intrinsic function for a PRNG. A user can, of
course, write a function to give a PRN. Fortran's
PRNG is an intrinsic subroutine.

Fortran also offers the pure and impure prefix in a
function declaration. 'pure foo(a)' is guaranteed
to have no side effects, which allows a compiler
fairly aggressive in optimizing code. 'impure
foo(a)' tells the compiler "Beware dragons may be
here."

PS: Yes. Functions with side effects are evil. If
you wish to be conservative (or continue to wish to
argue), within the Fortran realm functions with
side effects are evil.
--
steve
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.fortran

On Sun, 3 May 2026 01:01:19 -0000 (UTC), Steven G. Kargl wrote:

On Sat, 2 May 2026 23:17:51 -0000 (UTC), Lawrence D’Oliveiro wrote:

On Sat, 2 May 2026 18:49:39 -0000 (UTC), Steven G. Kargl wrote:

(Yes, a function with a side-effct is evil).

Not necessarily. There are these things called “memo-functions”,
which cache computed results so they can save redoing the
computation if they are given the same set of args later.

Updating the cache is a side-effect, which speeds up execution. Is
that “evil”? I don’t think so.

A better example is a PRNG function.

I’m sure it is. But you didn’t qualify your claim with any such
caveats, did you?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.fortran

On Sun, 3 May 2026 00:52:45 -0000 (UTC), Steven G. Kargl wrote:

On Sat, 2 May 2026 23:19:50 -0000 (UTC), Lawrence D’Oliveiro wrote:

On Sat, 2 May 2026 18:49:39 -0000 (UTC), Steven G. Kargl wrote:

if (a > b .and. c > foo(a)) then

Here, the Fortran standard does not specify the order of
evaluation for a > b and c > foo(a). In addition, both operands of
.and. will be evaluated.

Somehow I don’t think they will. Otherwise GNU Fortran would not do
short-circuit evaluation when any significant level of optimization
is turned on.

Yeah, gfortran has made a processor-dependent choice to evaluate
expressions left-to-right. That's not required by the Fortran
standard *except for conditional expressions*.

But you said that “both operands ... *will* be evaluated”. Not “both operands *may* be evaluated”. The implication being that the
implementation is not supposed to have a choice.
--- Synchronet 3.22a-Linux NewsLink 1.2