On Friday, July 2, 2021 at 1:58:24 AM UTC+10, Beliavsky wrote:

See https://fortran-lang.discourse.group/t/poll-fortran-202x-conditional-expressions-syntax/1425/80?u=beliavsky referencing https://j3-fortran.org/doc/year/21/21-157r2.txt with code example

y = ( i>=1 .And. i<=Size(a) ? a(i) : -Huge(y) )

.
bizarre syntax, cryptic, and archaic.
It seems to be an attempt to revive something from Algol 60, viz,
y = if a>b then x else z;
which is less bizarre.
.

equivalent to

if (i>=1 .And. i<=Size(a)) then
y = a(i)
else
y = -Huge(y)
end if

I think it will be a nice addition to the language, inspired by the ternary operator of C.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wednesday, July 7, 2021 at 7:09:50 AM UTC-7, dpb wrote:

(snip)

I grant the first is powerful and makes it worth it for that reason.

j=0
if(a) j=ior(j,1)
if(b) j=ior(j,2)
if(c) j=ior(j,4)
select case(j)
case (0)
call sub(,,)
case (1)
call sub(a,,)
case (2)
call sub(,b,)
case (3)
call sub(a,b,)
case (4)
call sub(,,c)
case (5)
call sub(a,,c)
case (6)
call sub(,b,c)
case (7)
call sub(a,b,c)
end select

Yes, not so terse.

Other uses, as noted above, can also be done with MERGE.

As for the second, I suppose one eventually gets familiar-enough with
the idiom it isn't so obfuscating, but personally I still find it more confusing than helpful in C albeit I'll be first to admit have written
only as much C as was forced into over the last 40 years.

If one likes terse, that's one's privilege and I'm first to agree the language shouldn't go out of its way to prevent the user from coding as
suits their style/taste.

if(l) then
print *,a,x,c
else
print *,a,y,c
endif

Or use a temporary variable:

t=y
if(l) t=x
print *,a,t,c

or MERGE

print *,a,MERGE(x,y,l),c

or the new operator

print *,a, l?x:y, c

However, MERGE, like most function calls, evaluates its arguments
before executing the function. (That is, except for inquiry functions.)

print *,a,MERGE(x(i), y(j),l), c

evaluates array references which might have out of bounds subscripts.
Defining MERGE not to evaluate an argument when not necessary,
even though no other function has that requirement, could have fixed this.

But, does the ternary form do anything to aid the compiler in producing
any better/faster/more optimized code than the equivalent if...end
construct?

Since it guarantees not to evaluate the unselected operand,
it could be faster than MERGE. I think it looks a lot better than
lots of temporary variables, just for storing selected values.
And a big advantage when you can't evaluate the other operand.

Either/both just turn into conditional branch/jump don't they? Same as
a computed GOTO vs a CASE structure; the point is more for the human
than the computer/compiler so there's advantages to clarity as well.

Many processors now have a conditional load instruction, which helps
avoid the uncertainty of branch destinations. But that only works
when you can actually evaluate all the operands.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le 07/07/2021 à 14:41, FortranFan a écrit :

On Wednesday, July 7, 2021 at 5:36:13 AM UTC-4, pehache wrote:

..
Apart from being more cryptic, I can't see any advantage over the
if/then/else construct
..

Re: ".. I can't see any advantage over the if/then/else construct ..," that is an incorrect assessment of this new feature in Fortran 202X.

As noted upthread, there can be considerable advantage with this feature when it comes to reference to procedures with optional arguments and the advantage scales rapidly with the number of optional arguments.

I don't really get that... An exemple maybe ?

Actually the advantage is that the result can be used directly within an expression, but there was no need to chose a cryptic syntax. As stated
in another post, something like
y = if (condition) then ; <expression> ; else ; expression ; endif

would have do

And to reiterate, the additional advantage is with those who seek compact code.

Fortran is not for compact code.

--
"...sois ouvert aux idées des autres pour peu qu'elles aillent dans le
même sens que les tiennes.", ST sur fr.bio.medecine

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

pehache <pehache.7@gmail.com> schrieb:

Actually the advantage is that the result can be used directly within an expression, but there was no need to chose a cryptic syntax. As stated
in another post, something like
y = if (condition) then ; <expression> ; else ; expression ; endif

would have do

There was one certainty: Whatever syntax was chosen, some people
would object :-)

The current one is rather similar to C, which means that people who
know the feature from other programming languages will recognize it.

Certainly good enough for me.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le 08/07/2021 à 16:22, Thomas Koenig a écrit :

pehache <pehache.7@gmail.com> schrieb:

Actually the advantage is that the result can be used directly within an
expression, but there was no need to chose a cryptic syntax. As stated
in another post, something like
y = if (condition) then ; <expression> ; else ; expression ; endif

would have do

There was one certainty: Whatever syntax was chosen, some people
would object :-)

The current one is rather similar to C, which means that people who
know the feature from other programming languages will recognize it.

I prefer new syntaxes that are consistent with existing Fortran rather
than new syntaxes that are consistent with C.

Even without any knowledge of Fortan, any developer is able to figure
out what does mean :
y = if (i>=1.and.i<=Size(a)) then ; a(i) ; else ; -Huge(y) ; endif

While only C* developers can figure out what does means :
y = ( i>=1.and.i<=Size(a) ? a(i) : -Huge(y) )

--
"...sois ouvert aux idées des autres pour peu qu'elles aillent dans le
même sens que les tiennes.", ST sur fr.bio.medecine

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, July 8, 2021 at 4:42:02 AM UTC-7, pehache wrote:

(snip, someone wrote)

As noted upthread, there can be considerable advantage with this feature when it
comes to reference to procedures with optional arguments and the advantage scales rapidly with the number of optional arguments.

I don't really get that... An exemple maybe ?

I wrote this above, calling a subroutine with three optional arguments, in
all combinations.

j=0
if(a) j=ior(j,1)
if(b) j=ior(j,2)
if(c) j=ior(j,4)
select case(j)
case (0)
call sub(,,)
case (1)
call sub(a,,)
case (2)
call sub(,b,)
case (3)
call sub(a,b,)
case (4)
call sub(,,c)
case (5)
call sub(a,,c)
case (6)
call sub(,b,c)
case (7)
call sub(a,b,c)
end select

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/8/21 8:38 PM, gah4 wrote:

On Thursday, July 8, 2021 at 4:42:02 AM UTC-7, pehache wrote:

(snip, someone wrote)

As noted upthread, there can be considerable advantage with this feature when it
comes to reference to procedures with optional arguments and the advantage >>> scales rapidly with the number of optional arguments.

I don't really get that... An exemple maybe ?

I wrote this above, calling a subroutine with three optional arguments, in all combinations.

j=0
if(a) j=ior(j,1)
if(b) j=ior(j,2)
if(c) j=ior(j,4)
select case(j)
case (0)
call sub(,,)
case (1)
call sub(a,,)
case (2)
call sub(,b,)
case (3)
call sub(a,b,)
case (4)
call sub(,,c)
case (5)
call sub(a,,c)
case (6)
call sub(,b,c)
case (7)
call sub(a,b,c)
end select

I would say this is confusing at best. The "a", "b", and "c" variables
are logical, and used to set j, which is only used to select the call.
But sub() is always called with .true. present arguments and .false'
nonpresent arguments (assuming that syntax even works), so why not just have

call sub(a,b,c)

to cover all the cases? The arguments have .true. or .false. values,
which the subprogram can test in the straightforward way. No need for
optional attributes, where the present dummy arguments are always .true.
and the nonpresent arguments are always .false.

On the other hand, if "a", "b", and "c" are themselves optional
arguments (of any type), then

call sub(a,b,c)

passes their present() status down to sub() in the straightforward way.
This is a very useful feature of the language (since f90).

An example of the conditional expression is

call sub( (<expression> ? a : b) )

which is equivalent to

if ( expression ) then
call sub(a)
else
call sub(b)
endif

Now consider a subroutine with more than one such argument. Each
argument would double the number of possible if-then-else branches
(O(2^N) coding effort) required to select the correct calling sequence,
but it can be done with a single call using the multiple conditional expressions (O(N) coding effort). Further, this cannot be done with
MERGE, because the result of MERGE is an modifiable expression. That
means it can be associated with intent(out) and intent(inout) dummy
arguments, and the updated values are passed back to the calling program correctly through the argument association.

This could also be achieved with pointers, conditionally assigning each
pointer actual argument. That approach also requires O(N) rather than
O(2^N) coding effort. However that would require that the possible
arguments all be targets, which suppresses optimization in the same way
that C, C++, etc. languages have suppressed optimization due to wild
pointers.

In my opinion, the fact that the result is modifiable is the real useful feature of the conditional expression semantics. When used to replace
MERGE or IF-THEN-ENDIF, it is mostly, apart from the short-circuit
feature, just redundant eye candy.

$.02 -Ron Shepard

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Friday, July 9, 2021 at 12:13:24 AM UTC-7, Ron Shepard wrote:

(snip of example. See above if you forgot it.)

I would say this is confusing at best. The "a", "b", and "c" variables
are logical, and used to set j, which is only used to select the call.
But sub() is always called with .true. present arguments and .false' nonpresent arguments (assuming that syntax even works), so why not just have

call sub(a,b,c)

Sorry, yes, I was not very original in my variable name choice.
Consider x, y, and z as the arguments instead.

(snip)

An example of the conditional expression is

call sub( (<expression> ? a : b) )

which is equivalent to

if ( expression ) then
call sub(a)
else
call sub(b)
endif

Now consider a subroutine with more than one such argument. Each
argument would double the number of possible if-then-else branches
(O(2^N) coding effort) required to select the correct calling sequence,
but it can be done with a single call using the multiple conditional expressions (O(N) coding effort). Further, this cannot be done with
MERGE, because the result of MERGE is an modifiable expression. That
means it can be associated with intent(out) and intent(inout) dummy arguments, and the updated values are passed back to the calling program correctly through the argument association.

I believe that MERGE cannot be used with intent(out) or intent(inout) arguments, but I haven't thought about this recently.

This could also be achieved with pointers, conditionally assigning each pointer actual argument. That approach also requires O(N) rather than
O(2^N) coding effort. However that would require that the possible
arguments all be targets, which suppresses optimization in the same way
that C, C++, etc. languages have suppressed optimization due to wild pointers.

In my opinion, the fact that the result is modifiable is the real useful feature of the conditional expression semantics. When used to replace
MERGE or IF-THEN-ENDIF, it is mostly, apart from the short-circuit
feature, just redundant eye candy.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 08/07/2021 14:41, pehache wrote:

I don't really get that... An exemple maybe ?
...

Fortran is not for compact code.

Here is a C function call. The last two arguments I've added use the
ternary operator. Without it the code fragment would be longer. But
when one needs to debug, this cryptic operator makes the task harder.

Some times I temporarily replace a ternary op in an assignment with a
classic If-Else statement to see what is really called.

Regards,
Ev. Drikos

---------------------------------------------------------------------

tmp = gfc_trans_scalar_assign (&lse, &rse, expr1->ts,
gfc_expr_is_variable (expr2)
|| scalar_to_array
|| expr2->expr_type == EXPR_ARRAY,
!(l_is_temp || init_flag) && dealloc,
expr1->symtree->n.sym->attr.codimension,
gfc_bt_struct (expr2->ts.type) &&
(gfc_expr_is_variable (expr2)
|| scalar_to_array
|| expr2->expr_type == EXPR_ARRAY
|| expr2->expr_type == EXPR_STRUCTURE)? expr1: NULL,
scalar_to_array && dealloc? NULL: expr2);

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 07/07/2021 08:15, Ev. Drikos wrote:

<conditional-argument> ::=
           <expr> ? <expr> -: { : }

Just for the record, Follow Restrictions aren't required in this rule,
whereas, the ternary operator is Right-Associative. So, I post again
along with an example (without questioning the recommended syntax).

Ev. Drikos

------------------
program example
v1 = f( x ? arg ); ! 1. Optional argument
v2 = x ? a : y ? b : z ! 2. Right associative ternary
operator as in C
v3 = f((x ? a : y ? b : z ) ? arg) ! 3. Parentheses required when 1
and 2 are nested
end
------------------

<actual-arg> ::=
<expr>
| <alt-return-spec>
| *
| <vms-argument>
| <conditional-argument>

<conditional-argument> ::=
<expr> ? <expr>

<expr> ::=
<expr> ? <expr> : <expr> -: { ? }
| <expr> <defined-binary-op> <expr>
| <expr> <equiv-op> <expr>
| <expr> <or-op> <expr>
| <expr> <and-op> <expr>
| <not-op> <expr>
| <expr> <rel-op> <expr> ~: <rel-op>
| <expr> <concat-op> <expr>
| <expr> <add-op> <expr>
| <expr> <mult-op> <expr>
| <expr> <power-op> <expr> -: { <power-op> }
| <unary-op> <expr> -: { <power-op> | <mult-op> }
| <primary>
| <defined-unary-op> <primary>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/9/21 2:41 AM, gah4 wrote:

Now consider a subroutine with more than one such argument. Each
argument would double the number of possible if-then-else branches
(O(2^N) coding effort) required to select the correct calling sequence,
but it can be done with a single call using the multiple conditional
expressions (O(N) coding effort). Further, this cannot be done with
MERGE, because the result of MERGE is an modifiable expression. That
means it can be associated with intent(out) and intent(inout) dummy
arguments, and the updated values are passed back to the calling program
correctly through the argument association.

I believe that MERGE cannot be used with intent(out) or intent(inout) arguments, but I haven't thought about this recently.

Yes, that was a typo in that sentence. I meant "unmodifiable" for MERGE,
in contrast to "modifiable" for the conditional expression.

$.02 -Ron Shepard

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Friday, July 9, 2021 at 1:01:27 PM UTC-7, Ron Shepard wrote:

(snip)

I believe that MERGE cannot be used with intent(out) or intent(inout) arguments, but I haven't thought about this recently.

Yes, that was a typo in that sentence. I meant "unmodifiable" for MERGE,
in contrast to "modifiable" for the conditional expression.

That is what I suspected, but wanted to make sure, so no-one else
gets confused.

I think the ability not to evaluate both arguments could have been added to merge. But modifiable arguments would have been a less obvious addition.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Steve Lionel schrieb am Dienstag, 6. Juli 2021 um 16:44:04 UTC+2:

On 7/6/2021 2:41 AM, Ron Shepard wrote:

And since it is modifiable, I'm wondering if it can be used on the left hand side of an equals sign?

No.The syntax added is for a conditional expression, which can be a
"primary" in an expression (see https://stevelionel.com/drfortran/2021/04/03/doctor-fortran-in-order-order/), or as a conditional actual argument in a procedure reference.

There is nothing I can think of that would block adding this third usage
in the future, but it was not included in the design.

It might be quite easy to add the little bits that would permit

ASSOCIATE ( a => <conditional expr> )
a = ...
END ASSOCIATE

since the relationship to argument association is so close.

Cheers
Reinhold

--
Steve Lionel
ISO/IEC JTC1/SC22/WG5 (Fortran) Convenor
Retired Intel Fortran developer/support
Email: firstname at firstnamelastname dot com
Twitter: @DoctorFortran
LinkedIn: https://www.linkedin.com/in/stevelionel
Blog: https://stevelionel.com/drfortran
WG5: https://wg5-fortran.org

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Friday, July 9, 2021 at 12:22:59 AM UTC+10, Thomas Koenig wrote:

pehache <peha...@gmail.com> schrieb:

Actually the advantage is that the result can be used directly within an expression, but there was no need to chose a cryptic syntax. As stated
in another post, something like
y = if (condition) then ; <expression> ; else ; expression ; endif

would have do

There was one certainty: Whatever syntax was chosen, some people
would object :-)

The current one is rather similar to C, which means that people who
know the feature from other programming languages will recognize it.

Certainly good enough for me.

Would the limited "if then else" structure of the conditional expression provide opportunity for improved optimisation ?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Saturday, July 10, 2021 at 9:19:53 PM UTC-7, JCampbell wrote:

(snip)

Would the limited "if then else" structure of the conditional expression provide opportunity for improved optimisation ?

As well as I know, MERGE is allowed to optimize, only evaluating one argument, but isn't required to do that. The new operator requires it.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/11/21 2:26 PM, gah4 wrote:

On Saturday, July 10, 2021 at 9:19:53 PM UTC-7, JCampbell wrote:

(snip)

Would the limited "if then else" structure of the conditional expression provide opportunity for improved optimisation ?

As well as I know, MERGE is allowed to optimize, only evaluating one argument,
but isn't required to do that. The new operator requires it.

That hypothetical situation works the other way too. MERGE is allowed to optimize by evaluating its arguments early (reusing register values,
minimizing memory references, reusing allocated temporary arrays, etc.),
and the new operator forbids that optimization, requiring the short
circuit semantics instead.

$.02 -Ron Shepard

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/7/2021 11:34 PM, Robin Vowels wrote:

On Friday, July 2, 2021 at 1:58:24 AM UTC+10, Beliavsky wrote:

See https://fortran-lang.discourse.group/t/poll-fortran-202x-conditional-expressions-syntax/1425/80?u=beliavsky referencing https://j3-fortran.org/doc/year/21/21-157r2.txt with code example

y = ( i>=1 .And. i<=Size(a) ? a(i) : -Huge(y) )

.
bizarre syntax, cryptic, and archaic.
It seems to be an attempt to revive something from Algol 60, viz,
y = if a>b then x else z;
which is less bizarre.
.

equivalent to

if (i>=1 .And. i<=Size(a)) then
y = a(i)
else
y = -Huge(y)
end if

I think it will be a nice addition to the language, inspired by the ternary operator of C.

We agree on something. I have never used this syntax in C as I dislike it.

Lynn

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Monday, July 12, 2021 at 9:26:05 AM UTC-7, Ron Shepard wrote:

(snip, I wrote)

As well as I know, MERGE is allowed to optimize, only evaluating one argument,
but isn't required to do that. The new operator requires it.

That hypothetical situation works the other way too. MERGE is allowed to optimize by evaluating its arguments early (reusing register values, minimizing memory references, reusing allocated temporary arrays, etc.),
and the new operator forbids that optimization, requiring the short
circuit semantics instead.

I suppose so. Well, it is only a problem with side effects.

As far as I know, the biggest side effect is array references.
I have a program from the Fortran 66 days with:

970 IF ((B.LE.0.OR.IB(B).NE.LL+1)) GO TO 1010

As long as you don't do bounds checking, it works fine.
I suspect that in the logic, B can be zero, or maybe slightly
negative, but not so far to get outside the program's memory
space.

But there are more ways to have side effects in C.

printf("%d", s? a[i++] : b[j++]);

depending on which one is selected, i or j is incremented,
but also the array reference has to be in bounds.

But the Fortran rules on side-effects are different from C, and I suspect
still apply in this case.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Monday, July 12, 2021 at 1:50:58 PM UTC-7, Lynn McGuire wrote:

(snip, someone wrote)

I think it will be a nice addition to the language, inspired by the ternary operator of C.

We agree on something. I have never used this syntax in C as I dislike it.

Fun with the C preprocessor:

#define MERGE(x, y, z) ((z) ? (x) : (y))

There is a long history of people using the C preprocessor to
avoid parts of C that they don't like. Rumors of Pascal users:

#define BEGIN {
#define END {

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

There is a long history of people using the C preprocessor to
avoid parts of C that they don't like. Rumors of Pascal users:

#define BEGIN {
#define END {

I assume you mean

#define END }

:-)

And it fact that the original Bourne shell was written in a style
like that. Stephen Bourne was rather unique in that he was a
fan of Algol 68, which is why the Unix shell has some syntax
details inspired by that language.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <scj76j$b87$1@newsreader4.netcologne.de>, Thomas Koenig <tkoenig@netcologne.de> writes:

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

There is a long history of people using the C preprocessor to
avoid parts of C that they don't like. Rumors of Pascal users:

#define BEGIN {
#define END {

I assume you mean

#define END }

:-)

And it fact that the original Bourne shell was written in a style
like that. Stephen Bourne was rather unique in that he was a
fan of Algol 68, which is why the Unix shell has some syntax
details inspired by that language.

A Fortran programmer can write Fortran in any language.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/13/2021 2:33 AM, Phillip Helbig---undress to reply wrote:

In article <scj76j$b87$1@newsreader4.netcologne.de>, Thomas Koenig <tkoenig@netcologne.de> writes:

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

There is a long history of people using the C preprocessor to
avoid parts of C that they don't like. Rumors of Pascal users:

#define BEGIN {
#define END {

I assume you mean

#define END }

:-)

And it fact that the original Bourne shell was written in a style
like that. Stephen Bourne was rather unique in that he was a
fan of Algol 68, which is why the Unix shell has some syntax
details inspired by that language.

A Fortran programmer can write Fortran in any language.

Heh. I resemble that.

Lynn

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

czwartek, 1 lipca 2021 o 17:58:24 UTC+2 Beliavsky napisał(a):

See https://fortran-lang.discourse.group/t/poll-fortran-202x-conditional-expressions-syntax/1425/80?u=beliavsky referencing https://j3-fortran.org/doc/year/21/21-157r2.txt with code example

y = ( i>=1 .And. i<=Size(a) ? a(i) : -Huge(y) )

equivalent to

if (i>=1 .And. i<=Size(a)) then
y = a(i)
else
y = -Huge(y)
end if

I think it will be a nice addition to the language, inspired by the ternary operator of C.

It is a bit disappointing that instead of borrowing syntax from modern languages (such as Python), it is taken from outdated languages (C). Sadly, while the functionality is a step forward, and I'm very excited to use it, syntactically it's a mess, as it
comes from a totally unrelated language. Was there any motivation of such a choice over more modern syntax, such as this?

y = a(i) if i>=1 .and. i<=Size(a) else -Huge(y)

Dominik

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Dominik wrote:

Was there any motivation of such a choice over more modern syntax, such as this?
y = a(i) if i>=1 .and. i<=Size(a) else -Huge(y)

I feel it is interesting (and a bit surprising) that the committee chose the C-like ternary
form, but as for the above Python form, isn't it "problematic" to use for fixed-form
source form with the (notorious) implicit rule? (because spaces are neglected), e.g.,

program main
integer, parameter :: lo = 0, hi = 5
integer :: i
real :: a, b
read *, i
a = 1.23; b = 4.56
print *, a if i >= lo .and. i < hi else b
end

$ gfortran-10 test.f
$ ./a.out !! results are meaningless, but it compiles + gives some value
-1
T

I believe it is better to introduce a new syntax only for free-form + implicit none codes
(then there is no need for such consideration for neglect of spaces etc).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, September 2, 2021 at 8:58:51 AM UTC-4, spectrum wrote:

..
I feel it is interesting (and a bit surprising) that the committee chose the C-like ternary
form, but as for the above Python form, isn't it "problematic" to use for fixed-form
source form with the (notorious) implicit rule? (because spaces are neglected), e.g., ..

In essence, @spectrum is right: the committee did consider quite a few options but the need for the syntax to also work with fixed-form source filtered out most.

This is among several reasons I now feel the Fortran standard needs to have a third category of outmoded features, say RETIRED. Please see this:
https://github.com/j3-fortran/fortran_proposals/issues/225#issue-979802884

Fixed-form has been obsolescent since Fortran 95 which was nearly 25 years ago. So technically an entire generation has grown up knowing the fixed-form source is not only too limiting but it also officially recognized as outmoded.

But still no matter what, the chances of fixed-form source ever going to be deleted from the standard might very well be the definition of absolute zero. The entrenched interests and intransigence when it comes to moving beyond fixed-form source is
insurmountable.

But then also, the chances of any modern Fortran features such as conditional expressions being used in fixed-form source are low enough to be statistically insignificant.

Considering all this, can everyone involved with Fortran please come to a consensus and understanding and at least retire fixed-form source so as to *not* to burden any and all current (like with conditional expressions in the case of this thread) and
future features (Generics, exception handling, etc.) and specifically their syntax with the need to have backward compatibility with fixed-form source where blanks are insignificant?

Can the Fortran standard at least mark fixed-form source as RETIRED? Please.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 03.09.21 um 16:53 schrieb FortranFan:

On Thursday, September 2, 2021 at 8:58:51 AM UTC-4, spectrum wrote:

the need to have backward compatibility with fixed-form source where
blanks are insignificant?

Can the Fortran standard at least mark fixed-form source as RETIRED? Please.

I greatly support that idea. There will always be compiler options that
allow compilation of such legacy codes, but all new features in my
opinion only really need to properly work with free-form.

--
Juergen Reuter
Theoretical Particle Physics
Deutsches Elektronen-Synchrotron (DESY)
Hamburg, Germany

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, September 2, 2021 at 3:41:35 AM UTC-7, gro...@gmail.com wrote:

(snip)

Was there any motivation of such a choice over more modern syntax, such as this?

y = a(i) if i>=1 .and. i<=Size(a) else -Huge(y)

VHDL has

y <= a(i) when i>1 and i<=s else j;

and I hate it. Well, for one, I learned verilog first, which I like better for lots of other reasons,
but one reason I don't like that form of the operator is that it has the wrong symmetry.

I can see it with the selecting expression first, or (like in RPN languages) last,
but it seems wrong in the middle. It looks even worse when nested.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

JRR <juergen.reuter@invalid.com> schrieb:

Am 03.09.21 um 16:53 schrieb FortranFan:

On Thursday, September 2, 2021 at 8:58:51 AM UTC-4, spectrum wrote:

the need to have backward compatibility with fixed-form source where
blanks are insignificant?

Can the Fortran standard at least mark fixed-form source as RETIRED? Please.

I greatly support that idea. There will always be compiler options that
allow compilation of such legacy codes, but all new features in my
opinion only really need to properly work with free-form.

A basic problem with marking features obsolete is that the
interaction between those features and newer ones is no longer
defined.

If all compilers will continue to support the old feature, this
creates ambiguity for the compiler writers and the users, which
is a Bad Thing (TM).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, September 5, 2021 at 5:44:48 AM UTC-4, Thomas Koenig wrote:

..
If all compilers will continue to support the old feature, this
creates ambiguity for the compiler writers and the users, which
is a Bad Thing (TM).

A honest reckoning with reality is a Fortran standard does not dare to obsolesce and retire certain unsavory features from earlier revisions is a Much, Much Worse Thing (no TM) for the practitioners.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 9/4/21 2:53 PM, JRR wrote:

Am 03.09.21 um 16:53 schrieb FortranFan:

On Thursday, September 2, 2021 at 8:58:51 AM UTC-4, spectrum wrote:

 the need to have backward compatibility with fixed-form source where blanks are insignificant?

Can the Fortran standard at least mark fixed-form source as RETIRED?
Please.

I greatly support that idea. There will always be compiler options that
allow compilation of such legacy codes, but all new features in my
opinion only really need to properly work with free-form.

Are there any current fortran statements or features that can only be
used in free-source form? If not, then adopting such a feature would be
a new direction for the language.

If such a feature were introduced, and if it were possible to introduce
a compiler option that would override the standard and allow the new
feature to be used in fixed-source form, then why couldn't the standard
have been written that way to begin with, thus avoiding the
compatibility problem altogether?

$.02 -Ron Shepard

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 07/09/2021 00:31, Ron Shepard wrote:

...
thus avoiding the
compatibility problem altogether?

Introducing a new feature that can't be used in the older fixed-form
doesn't break backward compatibility.

Ev. Drikos

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 9/8/21 7:22 AM, Ev. Drikos wrote:

On 07/09/2021 00:31, Ron Shepard wrote:

...
thus avoiding the compatibility problem altogether?

Introducing a new feature that can't be used in the older fixed-form
doesn't break backward compatibility.

This is a correct answer to a different question. My question was about compiler options to allow new features to be used in fixed-form, not
backwards compatibility with existing code.

$.02 -Ron Shepard

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ron Shepard <nospam@nowhere.org> schrieb:

On 9/8/21 7:22 AM, Ev. Drikos wrote:

On 07/09/2021 00:31, Ron Shepard wrote:

...
thus avoiding the compatibility problem altogether?

Introducing a new feature that can't be used in the older fixed-form
doesn't break backward compatibility.

This is a correct answer to a different question. My question was about compiler options to allow new features to be used in fixed-form, not backwards compatibility with existing code.

It could be done, but that would be trying to clear up an unnecessary
mess. Fortran has survived with fixed and free form since 1991 with
all new features so far, adding something to the language that breaks
that is not necessary. (I'm also hard pressed to think of a reasonable example).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 07/09/2021 00:31, Ron Shepard wrote:

On 9/4/21 2:53 PM, JRR wrote:

Am 03.09.21 um 16:53 schrieb FortranFan:

On Thursday, September 2, 2021 at 8:58:51 AM UTC-4, spectrum wrote:

  the need to have backward compatibility with fixed-form source where
blanks are insignificant?

Can the Fortran standard at least mark fixed-form source as RETIRED?
Please.

I greatly support that idea. There will always be compiler options
that allow compilation of such legacy codes, but all new features in
my opinion only really need to properly work with free-form.

Are there any current fortran statements or features that can only be
used in free-source form? If not, then adopting such a feature would be
a new direction for the language.

If such a feature were introduced, and if it were possible to introduce
a compiler option that would override the standard and allow the new
feature to be used in fixed-source form, then why couldn't the standard
have been written that way to begin with, thus avoiding the
compatibility problem altogether?

OK, I repeat my response including the relevant earlier response by
FortranFan: "Introducing a new feature that can't be used in the older fixed-form doesn't break backward compatibility."


@Ron Shepard
Assuming the fixed-form is the "old", your question (possibly rhetoric?) implies why "forward compatibility" shall be abandoned since the
standard is written that way for a long time (30 years or so).

So, the question here is in what way "forward" compatibility is useful,
maybe for the intersection format?


Regards,
Ev. Drikos

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ev. Drikos <drikosev@gmail.com> schrieb:

OK, I repeat my response including the relevant earlier response by FortranFan: "Introducing a new feature that can't be used in the older fixed-form doesn't break backward compatibility."

It just introduces arbitrary incompatibility into the language, for
which there is no need.

Not a good idea.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Friday, September 10, 2021 at 11:03:37 AM UTC-4, Thomas Koenig wrote:

Ev. Drikos <drik...@gmail.com> schrieb:

OK, I repeat my response including the relevant earlier response by FortranFan: "Introducing a new feature that can't be used in the older fixed-form doesn't break backward compatibility."

It just introduces arbitrary incompatibility into the language, for
which there is no need.

The "no need" part is the other way around. Formula translation need NOT remain tied to fixed-form source format any more than someone who asks for every new statement feature to integrate well with ASSIGN from FORTRAN I, all support for character
intrinsic types and internationalization to work with Hollerith from FORTRAN I, all IO facilities to also work with PUNCH statement from FORTRAN I and also differentiate between IO toward TAPE and DRUM, all compiler optimizations to be driven by
FREQUENCY statement from FORTRAN I, all numerical (and floating-point) exceptions to also work with ACCUMULATOR OVERFLOW from FORTRAN I, all processors to also recognize SENSOR LIGHT on/off toggle from FORTRAN I, etc. will be ignored.

Not a good idea.

Re: "Not a good idea," it is quite an opinion alright. The Fortran Community better realize soon such an opinion does nothing useful now i.e., which is 30 years since free-form was introduced - all it does is hold Fortran hostage. The Community needs
to coalesce and start to overrule such an opinion expressly.

The Community needs to start thinking earnestly about Fortran 202Y standard revision now. The revision 202Y can potentially include Generics and Exception Handling, two crucial aspects for Fortran that Fortranners require toward modern applications of
the language in the *actual* practice of scientific and technical computing. That is, applications using Fortran in scientific and technical domains beyond the hobbyist or "keep the lights on until xx" type of projects and endeavors that can and will
continue forever even if Fortran standard development had remained frozen with ANSI X-3.9 1978, or the Fortran 90 revision. The continuing standard development better have vision beyond old codes and hobbyist efforts in the same mode.

But now, the very idea that the semantics and more importantly from the practitioner perspective the syntax for Generics, Exception Handling, ETC. all have to be designed to work with fixed-form source must be accepted as too limiting. By the time one
can expect Fortran 202Y to be practically effective in terms of compiler implementations, it will be circa 2040(!) and it will have been nearly 50 years since free-form source got added i.e., nearly 2 generations later. Why put the fixed-form source and
a few other things from FORTRAN as millstone around the necks of future generations?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Friday, September 10, 2021 at 11:04:30 AM UTC-7, FortranFan wrote:

(snip)

The "no need" part is the other way around. Formula translation need NOT remain tied
to fixed-form source format any more than someone who asks for every new
statement feature to integrate well with ASSIGN from FORTRAN I, all support
for character intrinsic types and internationalization to work with Hollerith
from FORTRAN I, all IO facilities to also work with PUNCH statement
from FORTRAN I and also differentiate between IO toward TAPE and DRUM,
all compiler optimizations to be driven by FREQUENCY statement from FORTRAN I,
all numerical (and floating-point) exceptions to also work with ACCUMULATOR OVERFLOW from FORTRAN I, all processors to also recognize SENSOR LIGHT
on/off toggle from FORTRAN I, etc. will be ignored.

There are two different things, sometimes called syntax and semantics.

When adding new features, one must be sure that the syntax doesn't create ambiguities in parsing. That is complicated in fixed form because blanks are ignored. No reserved words complicates both forms, but is, I believe, a worthwhile feature to Fortran. Keeping the old statements is mostly not
a problem for parsing.

Reminds me, though, the SLITE and SLITET, sense light and sense light test, routines are in OS/360 Fortran, though there are no actual lights. One can turn on and off the virtual lights, and test them. (That is, four logical values.)

I did always find it interesting that the Fortran II style I/O statements, that went
away in Fortran IV (and 66), came back later. (Though not the tape and drum versions.) OS/360 Fortran supports READ (for unit 5), PRINT (for unit 6)
and PUNCH (for unit 7). (There is no requirement that unit 7 actually
be a card punch or, more usually, SYSOUT=B.)

I do like using PRINT for debugging, as it is easy to recognize as different from the actual I/O statements.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10/09/2021 22:08, gah4 wrote:

No reserved words complicates both forms, but is, I believe, a
worthwhile feature to Fortran.

It is a worthwhile feature because the standard doesn't invalidate
ie existing code that already uses the newer keywords as variables.

Ev. Drikos

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

piątek, 10 września 2021 o 17:03:37 UTC+2 Thomas Koenig napisał(a):

Ev. Drikos <drik...@gmail.com> schrieb:

OK, I repeat my response including the relevant earlier response by FortranFan: "Introducing a new feature that can't be used in the older fixed-form doesn't break backward compatibility."

It just introduces arbitrary incompatibility into the language, for
which there is no need.

Not a good idea.

In my opinion there is need, because it is another situation when "this will break fixed format" is used as an argument. And this argument is invalid. Because there is "no need" to use the fixed form for anything. It is only for old codes, which live in
different files, away from Modern Fortran. It is possible and *very easy* to call old routines from Modern Fortran. Mixing old and new Fortran in one file is against good practices anyway.

It is not arbitrary, since it clearly slows down the development of the language. It is a burden, and detaching this burden would enable many new solutions to be introduced into Fortran and make it more relevant for new projects.

To call something "needed" or "not needed", there must be a working scenario in which the change would help. There is no real scenario where using modern features in fixed form would yield a good outcome. But there are many fields where the opposite (
clear separation) would be beneficial.

Dominik

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, September 30, 2021 at 8:40:28 AM UTC-4, gro...@gmail.com wrote:

piątek, 10 września 2021 o 17:03:37 UTC+2 Thomas Koenig napisał(a):
..

FortranFan: "Introducing a new feature that can't be used in the older fixed-form doesn't break backward compatibility."

It just introduces arbitrary incompatibility into the language, for
which there is no need.

Not a good idea.

In my opinion there is need, because it is another situation when "this will break fixed format" is used as an argument. And this argument is invalid. Because there is "no need" to use the fixed form for anything. It is only for old codes, which live

in different files, away from Modern Fortran. It is possible and *very easy* to call old routines from Modern Fortran. Mixing old and new Fortran in one file is against good practices anyway.

It is not arbitrary, since it clearly slows down the development of the language. It is a burden, and detaching this burden would enable many new solutions to be introduced into Fortran and make it more relevant for new projects.

To call something "needed" or "not needed", there must be a working scenario in which the change would help. There is no real scenario where using modern features in fixed form would yield a good outcome. But there are many fields where the opposite (

clear separation) would be beneficial.

Dominik

@Dominik, thumbs up to everything you write. Can you please offer your feedback at this thread?
https://github.com/j3-fortran/fortran_proposals/issues/225#issue-979802884

And/or, offer any alternate suggestions if you disagree with this GitHub thread I link here. Because something has gotta give if Fortran is to advance and better, firmer proposals are thus necessary.

Thank you,

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Saturday, September 11, 2021 at 5:08:09 AM UTC+10, gah4 wrote:

On Friday, September 10, 2021 at 11:04:30 AM UTC-7, FortranFan wrote:

(snip)

The "no need" part is the other way around. Formula translation need NOT remain tied
to fixed-form source format any more than someone who asks for every new statement feature to integrate well with ASSIGN from FORTRAN I, all support for character intrinsic types and internationalization to work with Hollerith
from FORTRAN I, all IO facilities to also work with PUNCH statement
from FORTRAN I and also differentiate between IO toward TAPE and DRUM,
all compiler optimizations to be driven by FREQUENCY statement from FORTRAN I,
all numerical (and floating-point) exceptions to also work with ACCUMULATOR OVERFLOW from FORTRAN I, all processors to also recognize SENSOR LIGHT on/off toggle from FORTRAN I, etc. will be ignored.

There are two different things, sometimes called syntax and semantics.

When adding new features, one must be sure that the syntax doesn't create ambiguities in parsing. That is complicated in fixed form because blanks are ignored. No reserved words complicates both forms, but is, I believe, a worthwhile feature to Fortran. Keeping the old statements is mostly not
a problem for parsing.

Reminds me, though, the SLITE and SLITET, sense light and sense light test, routines are in OS/360 Fortran, though there are no actual lights. One can turn on and off the virtual lights, and test them. (That is, four logical values.)

I did always find it interesting that the Fortran II style I/O statements, that went
away in Fortran IV (and 66), came back later. (Though not the tape and drum versions.) OS/360 Fortran supports READ (for unit 5), PRINT (for unit 6)
and PUNCH (for unit 7). (There is no requirement that unit 7 actually
be a card punch or, more usually, SYSOUT=B.)

I do like using PRINT for debugging, as it is easy to recognize as different from the actual I/O statements.

.
PRINT IS an actual I/O statement.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)