f2c updated to handle Fortran structures

[Lynn McGuire]

Does know if anyone updated f2c to convert Fortran data structures to C
data structures ?
https://www.netlib.org/f2c/

I am contemplating using a modified f2c to convert our 850,000 lines of
F77 in 5,000 subroutines to C++ code. I will modify f2c to meet my needs.

I asked the Netlib maintainer and he does not know of any.

Thanks,
Lynn

[gah4]

On Thursday, May 26, 2022 at 2:35:21 PM UTC-7, Lynn McGuire wrote:
> Does know if anyone updated f2c to convert Fortran data structures to C
> data structures ?
> https://www.netlib.org/f2c/

Since f2c is supposed to be Fortran 77, it wouldn't have structures.

I do remember that some DEC compilers might have had them.

As far as I know, f2c doesn't make readable C code. With some work,
you might get it to do more like what you want to see.

[Robin Vowels]

On Friday, May 27, 2022 at 7:35:21 AM UTC+10, Lynn McGuire wrote:
> Does know if anyone updated f2c to convert Fortran data structures to C
> data structures ?
> https://www.netlib.org/f2c/
>
> I am contemplating using a modified f2c to convert our 850,000 lines of
> F77 in 5,000 subroutines to C++ code. I will modify f2c to meet my needs.

The F77 code would be better updated to F90 or later form.

Silverfrost f95 can do it as part of the compilation process.
However, it does not transcribe the comments.

[Beliavsky]

As I have tweeted https://github.com/Beliavsky/FortranTip/blob/main/topics.md,

Use the bind(c) attribute to make a derived type compatible with C, with restrictions listed at https://gcc.gnu.org/onlinedocs/gfortran/Derived-Types-and-struct.html. For example,

type, bind(c) :: date
integer (kind=c_int) :: year, month
end type

interoperates with

typedef struct {
int year, month;
} date;

[Lynn McGuire]

Please, you are making massive assumptions about my environment.

Lynn

[CyrMag]

This is how f2c is described by its own authors:

"The converter f2c is a copy of the f77 Fortran compiler which has been altered to print out a C representation of the program being converted. The program f2c is a horror, based on ancient code and hacked unmercifully. Users are only supposed to look at its C output, not at its appalling inner workings."

If your 850,000 lines of F77 use nonstandard extensions of Fortran 77 such as DEC structures, unions, Cray pointers, etc., I suggest that you consider something other than f2c.

[Robin Vowels]

.
Is this the project that for years you have been saying that you
want to convert to modern Fortran ?
.
I have had considerable experience in converting F77 and earlier
to F90+ and other languages,
In the process, I uncovered numbers of bugs in the F77 and
earlier sources.
.
Converting your 850,000 lines of code to F90 would be a
massive enough job of itself, let alone to a completely
different language.
.
That's why I suggested updating the code to F90 or later.

[Lynn McGuire]

Yes. I have changed my mind. I am going to convert my Fortran
structures to an equivalenced double precision array and a integer*8
array (like I used to have from 1977 to 2002, only an equivalenced
single real array and integer*4 array). Then I am going to start
running my modified f2c on it. F2c already converts integer*8 to a long
long int.

I have been running extensive tests on f2c. The generated c code is
very good about converting the algorithms across the language barrier.
And the code is good (there is one array bug though). The translated
read and write code is freaking horrible so I've got to make it better.
Which, people have already noted and worked on.

https://www.researchgate.net/publication/220281652_Using_stdioh_in_the_Output_of_the_FORTRAN_to_C_Translator_f2c

BTW, my calculation engine is already about 10% C++ code. You cannot do
OLE2 in Fortran and my ZIP code is so highly tied to C bit twiddling. I
use extensive C++ glue code for manipulating embedded Excel spreadsheets
in my calculation engine and allowing my users to embed my calculation
engine in their VB, VBA (Excel VB), and C++ code.

Thanks,
Lynn

[Daniel Feenberg]

On Tuesday, May 31, 2022 at 12:07:43 AM UTC-4, Lynn McGuire wrote:
> On 5/30/2022 8:15 AM, Robin Vowels wrote:
> > On Saturday, May 28, 2022 at 7:14:32 AM UTC+10, Lynn McGuire wrote:
> >> On 5/27/2022 3:19 AM, Robin Vowels wrote:
> >>> On Friday, May 27, 2022 at 7:35:21 AM UTC+10, Lynn McGuire wrote:
> >>>> Does know if anyone updated f2c to convert Fortran data structures to C
> >>>> data structures ?
> >>>> https://www.netlib.org/f2c/
> >>>>
> >>>> I am contemplating using a modified f2c to convert our 850,000 lines of
> >>>> F77 in 5,000 subroutines to C++ code. I will modify f2c to meet my needs.
> >>>
> >>> The F77 code would be better updated to F90 or later form.
> >>>
> >>> Silverfrost f95 can do it as part of the compilation process.
> >>> However, it does not transcribe the comments.
> > .
> >> Please, you are making massive assumptions about my environment.
> > .
> > Is this the project that for years you have been saying that you
> > want to convert to modern Fortran ?
> > .
> > I have had considerable experience in converting F77 and earlier
> > to F90+ and other languages,
> > In the process, I uncovered numbers of bugs in the F77 and
> > earlier sources.

...

> Which, people have already noted and worked on.
>
> https://www.researchgate.net/publication/220281652_Using_stdioh_in_the_Output_of_the_FORTRAN_to_C_Translator_f2c
>

This URL includes a link to the improved f2c:

http://www.nag.co.uk:70/1h/public

but that link is dead. Does anyone know of an alternative source?

Daniel Feenberg

[Gary Scott]

I used DDE, OLE, OLE2, COM from Fortran for decades.

[Lynn McGuire]

Sounds like you are better programmer than me. How did you do the wide
character strings in OLE2 ?

Lynn

[Lynn McGuire]

I contacted NAG and they do not have the code anymore. Or they
incorporated it into their Fortran compiler. They were not sure. I did
not talk with the writer of the article though.

I did see something somewhat similar in Koenig's ??? Toolbox but I need
to investigate it further:
https://www.ibiblio.org/pub/Linux/devel/lang/fortran/!INDEX.short.html

Thanks,
Lynn

[Thomas Koenig]

Lynn McGuire <lynnmc...@gmail.com> schrieb:

> I did see something somewhat similar in Koenig's ??? Toolbox but I need
> to investigate it further:
> https://www.ibiblio.org/pub/Linux/devel/lang/fortran/!INDEX.short.html

Certainly not mine, I just ported the source to Linux (from a
HP-UX version) after having had good experience with it on MVS.
It originally came from NAG, I believe.

Toolpack has some nice restructuring features, but is _very_ picky
about strict F77 compliance. It does not even grok IMPLICIT NONE,
for example.

Regarding f2c - I just checked it on my Ubuntu system, and at least
I/O is broken there, something wrong with the library, I suppose.

I am also not sure if the games it plays for array dummy arguments
generate valid C or not. If you look at

subroutine foo(x,n)
dimension x(n)
x(1) = 1.
end

this gets translated to

/* Subroutine */ int foo_(real *x, integer *n)
{
/* Parameter adjustments */
--x;

/* Function Body */
x[1] = 1.f;
return 0;
} /* foo_ */

but for this another forum wold be more appropriate.

[gah4]

On Tuesday, May 31, 2022 at 1:02:50 PM UTC-7, Thomas Koenig wrote:

(snip)

> Regarding f2c - I just checked it on my Ubuntu system, and at least
> I/O is broken there, something wrong with the library, I suppose.
>
> I am also not sure if the games it plays for array dummy arguments
> generate valid C or not. If you look at
>
> subroutine foo(x,n)
> dimension x(n)
> x(1) = 1.
> end

> this gets translated to

> /* Subroutine */ int foo_(real *x, integer *n)
> {
> /* Parameter adjustments */
> --x;

> /* Function Body */
> x[1] = 1.f;
> return 0;
> } /* foo_ */

> but for this another forum wold be more appropriate.

This question came up often regarding "Numerical Recipes in C".

The reason it comes up at all in C, is there is no guarantee
that x-1 < x. If you require that, you have to be careful.

C guarantees that x+1 > x for x pointing to an actual variable
or array element, but not that x-1 < x. Don't, for example:

for(x=a+9; x>=a, x--) printf("%s", *x);

[Lynn McGuire]

That is valid C code and a valid pointer. But we do not like it so we
are going to rip out the --x parameter adjustment and subtract 1 from
the argument array addressing like f2c does for local arrays. That
means that we will not be able to modify portions of our F77 but all of
it at once.

Thanks,
Lynn

Lynn

[Gary Scott]

Structures and various operating system APIs allow interoperability. I
generally wrote simpler internal APIs to call from Fortran that did the
hard work and made it easier to use.

[Ron Shepard]

On 5/31/22 5:04 PM, Lynn McGuire wrote:
[...]

>> I am also not sure if the games it plays for array dummy arguments
>> generate valid C or not.  If you look at
>>
>>        subroutine foo(x,n)
>>        dimension x(n)
>>        x(1) = 1.
>>        end
>>
>> this gets translated to
>>
>> /* Subroutine */ int foo_(real *x, integer *n)
>> {
>>      /* Parameter adjustments */
>>      --x;
>>
>>      /* Function Body */
>>      x[1] = 1.f;
>>      return 0;
>> } /* foo_ */
>>
>> but for this another forum wold be more appropriate.
>
> That is valid C code and a valid pointer.

[...]

Others have already stated how it violates the C standard. The reason
for this restriction in C was that the array concept was based on a
segmented memory model. If the first element of the array happened to be
at a segment boundary, then decrementing the pointer meant that the
address was no longer necessarily even within the program's address
space. Depending on the OS, it could be pointing at some part of the OS,
or in a multitasking environment to the memory of another process. Then
later when virtual memory became popular, it could have resulted in page
address violations, depending on how exactly the virtual and actual
memory were mapped to each other. Such address computations could
trigger errors, even if the pointers were never referenced. The upper
range of the pointers were accounted for in the language. I think the
restriction was that the pointer was allowed to go one unit outside of
the array bound, but it could not be dereferenced once it was there.
There was no such allowance for the lower bound of the array, the
language simply did not allow the pointer outside that range, whether or
not it was later referenced or, as in the above example, incremented
back to within the valid array range.

$.02 -Ron Shepard

[Lynn McGuire]

Yes. I updated my Fortran code to call my OLE2 C++ code from my Win32
user interface when I needed to have two way discussions between my
calculation engine and Microsoft Excel.

Lynn

[Lynn McGuire]

Yes, very true. I am so used to programming in flat address planes now
that I don't even think about the good old days with segment pointers,
etc. Hopefully, we will never go back to those. After all, I am
starting the journey to 64 bit now.

Lynn

[gah4]

On Wednesday, June 1, 2022 at 8:24:36 AM UTC-7, Ron Shepard wrote:

(snip)

> Others have already stated how it violates the C standard. The reason
> for this restriction in C was that the array concept was based on a
> segmented memory model.

Well, even more than segmented, there used to be machines with
a tagged memory model. Each location had tags as to what kind
of value was stored there.

> If the first element of the array happened to be
> at a segment boundary, then decrementing the pointer meant that the
> address was no longer necessarily even within the program's address
> space.

Well, this could happen even without segmented memory, if the
array happened to be at the bottom of memory.

(To get back to the topic of this group, early Fortran compilers
allocated memory from the top of the address space down. Arrays
were stored in decreasing addresses in memory.)

In any case, yes, with protected mode x86, you can't load a segment
selector that doesn't select a valid segment descriptor, except for
the null selector, 0. In large model, though, only the offset is changed
with pointer arithmetic. In huge model, it will also change the
segment number. Even so, though, compilers usually won't load a
selector until you actually reference it, mostly because of code
like that. C guarantees that you can have a pointer to one past the
end of an array, and, more specifically, that it compares greater
than pointers into the array. That allows for loop tests based
on pointer values. Also, C doesn't allow (or doesn't define the
effect of) comparing pointers to different data items.

In the 80286 days, I was running OS/2 1.0 or 1.2, and allocating
segment selectors directly from the OS, with the exact length.
It was, then, a hardware exception even reading an array element
outside the array, and with no extra overhead. Very good for debugging
programs that might not be so good with array references.

> Depending on the OS, it could be pointing at some part of the OS,
> or in a multitasking environment to the memory of another process. Then
> later when virtual memory became popular, it could have resulted in page
> address violations, depending on how exactly the virtual and actual
> memory were mapped to each other.

Protected mode x86 is based on segments with a selector
and length. But as above, compilers would avoid unneeded
selector access to avoid the problem.

> Such address computations could
> trigger errors, even if the pointers were never referenced. The upper
> range of the pointers were accounted for in the language. I think the
> restriction was that the pointer was allowed to go one unit outside of
> the array bound, but it could not be dereferenced once it was there.

Yes. And so one less than the addressable space.

> There was no such allowance for the lower bound of the array, the
> language simply did not allow the pointer outside that range, whether or
> not it was later referenced or, as in the above example, incremented
> back to within the valid array range.

As above, compilers were good at avoiding that, but even so it can
still cause problems. Large model 16 bit x86 code only changes the offset,
and for other than equality and inequality, only compares the offset.
Even though it doesn't generate any access problems, the comparison
can fail.

[gah4]

On Wednesday, June 1, 2022 at 11:07:16 AM UTC-7, Lynn McGuire wrote:

(snip)

> Yes, very true. I am so used to programming in flat address planes now
> that I don't even think about the good old days with segment pointers,
> etc. Hopefully, we will never go back to those. After all, I am
> starting the journey to 64 bit now.

Reminds me, not so long ago I was working on a Fortran program
from the Fortran 66 days. There was then, and still isn't, short circuit
evaluation for logical expressions. This program had lots of

IF(J.LE.100 .AND. X(J).NE.0) ...

(for example) testing the array subscript and testing an array
value in the same IF statement. With many memory models,
that isn't much of a problem, especially if J stays close to the
ends of the array. However, it fails if bounds check is on.

I wanted to check the program for actual bounds errors,
and so had to change a lot of those!

[Thomas Koenig]

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

> Reminds me, not so long ago I was working on a Fortran program
> from the Fortran 66 days. There was then, and still isn't, short circuit
> evaluation for logical expressions. This program had lots of
>
> IF(J.LE.100 .AND. X(J).NE.0) ...
>
> (for example) testing the array subscript and testing an array
> value in the same IF statement. With many memory models,
> that isn't much of a problem, especially if J stays close to the
> ends of the array. However, it fails if bounds check is on.
>
> I wanted to check the program for actual bounds errors,
> and so had to change a lot of those!

A bit more problematic:

if (x .ne. 0. .and. y/x > 123.) then

...

Conditional expressions in Fortran will make it possible to
rewrite this as (hope I get this right)

if (( .not. x /= 0 ? .false. : y/x > 123.))

but the advantage of readability over

if (x .ne. 0) then
if (x/y > 123.) then

is certainly up for debate.

[Beliavsky]

I have wondered why certain statements are not allowed after the test
in the Fortran one-line if statement. Often I want to write something like

if (i > 0) if (x(i) > 0.0) print*,"i, x(i)=",i,x(i)

[gah4]

On Wednesday, June 1, 2022 at 6:31:17 PM UTC-7, Beliavsky wrote:

(snip)

> I have wondered why certain statements are not allowed after the test
> in the Fortran one-line if statement. Often I want to write something like

> if (i > 0) if (x(i) > 0.0) print*,"i, x(i)=",i,x(i)

As far as I know, it goes back to Fortran 66, and wasn't changed since.

In Fortran 66 days, compilers had to fit in small amounts of memory on
many machines, so some features were kept out.

Yes, I would have liked that.

[Robin Vowels]

.
Try
if (i > 0) then ; if (x(i) > 0.0) print etc ; end if

[Ron Shepard]

There was one other thing I wanted to add about the above C code. When
pointer arithmetic, such as the --x expression above, is performed, it
does not really add or subtract 1 to the hardware address. So there
isn't really a segment offset of 0 that get decremented by 1. What
really happens is that the hardware address is changed by the size of
the entity. That might be by 1 if the entity is a character array, but
if it is say a 4-byte integer, then it gets decremented by that size, or
if it is 54321-byte structure, then it gets decremented by 54321, etc.
If you think of C as a high-level assembler, then address arithmetic is
one of the few cases in the language where it looks more like a
high-level language than a low-level language.

$.02 -Ron Shepard

[FortranFan]

On Wednesday, June 1, 2022 at 9:31:17 PM UTC-4, Beliavsky wrote:

>
> I have wondered why certain statements are not allowed after the test
> in the Fortran one-line if statement. Often I want to write something like
>
> if (i > 0) if (x(i) > 0.0) print*,"i, x(i)=",i,x(i)

My understanding is starting Fortran 202X, the following will be conforming code based on the new feature introduction of *conditional expressions*:

if ( ( i > 0 ? ( if ( x(i) > 0.0 ) ? .true. : .false. ) : .false. ) ) print *, "i, x(i) = ", i , x(i)

[Ron Shepard]

One wonders, if they wanted to add something redundant to the language
to save typing a few extra characters, why didn't just add the above
fortran-like statement rather than incorporate the C-like syntax? Was
there any discussion about allowing the chained if statements?

$.02 -Ron Shepard

[FortranFan]

On Thursday, June 2, 2022 at 8:03:17 PM UTC-4, Ron Shepard wrote:

> ..

> One wonders, if they wanted to add something redundant to the language
> to save typing a few extra characters, why didn't just add the above
> fortran-like statement rather than incorporate the C-like syntax? Was

> there any discussion about allowing the chained if statements? ..

Anyone wondering can read a previous thread at this forum on this, especially the comments by @Steve Lionel who can provide the best commentary on the discussions:
https://groups.google.com/g/comp.lang.fortran/c/q8UaefqOFpc/m/V2m-eji0AQAJ

[gah4]

On Thursday, June 2, 2022 at 5:03:17 PM UTC-7, Ron Shepard wrote:

(snip, someone wrote)

> > if ( ( i > 0 ? ( if ( x(i) > 0.0 ) ? .true. : .false. ) : .false. ) ) print *, "i, x(i) = ", i , x(i)

> One wonders, if they wanted to add something redundant to the language
> to save typing a few extra characters, why didn't just add the above
> fortran-like statement rather than incorporate the C-like syntax? Was
> there any discussion about allowing the chained if statements?

Well, for one, chained IF only works for the .AND. operation.

In the case of .OR. with a GOTO statement, I just put in two separate
IF statements. I tend to do that less with a more complicated statement
on the IF, but sometimes.

The normal use for the conditional operator is not in IF statements,
but in other expressions.

Also, as well as I know it, the above could be written:

if ( i > 0 ? ( x(i) > 0.0 ) : .false. ) print *, "i, x(i) = ", i , x(i)

That is, the inner conditional operator isn't needed.

[FortranFan]

On Thursday, June 2, 2022 at 1:54:54 PM UTC-4, FortranFan wrote:

> ..

> My understanding is starting Fortran 202X, the following will be conforming code based on the new feature introduction of *conditional expressions*:
>
> if ( ( i > 0 ? ( if ( x(i) > 0.0 ) ? .true. : .false. ) : .false. ) ) print *, "i, x(i) = ", i , x(i)

Apologies, I made an error by including an `IF` in the inner expression. The following is what I think the Fortran 202X standard will allow:

if ( i > 0 ? ( x(i) > 0.0 ? .true. : .false. ) : .false. ) print *, "i, x(i) = ", i , x(i)

By the way, I do not think the brackets around the inner expression are needed per the BNF in the standard, that is the following should work as well:

if ( i > 0 ? x(i) > 0.0 ? .true. : .false. : .false. ) print *, "i, x(i) = ", i , x(i)

But I think many a coder will find it easier to comprehend the conditional-expr with the inner brackets, hence the first statement above for somewhat better clarity.

[gah4]

On Thursday, June 2, 2022 at 10:36:48 PM UTC-7, FortranFan wrote:

(snip)

> Apologies, I made an error by including an `IF` in the inner expression.

Some years ago I used an ALGOL system that used IF THEN ELSE for
its conditional operator:

X:= IF A>B THEN A ELSE B;

I think I like the C notation, but others might like that one.
I suspect it would cause problems in fixed form where blanks
(or lack of) are not significant. IF, THEN, and ELSE are
already reserved words in ALGOL.

[Ev. Drikos]

On 02/06/2022 04:31, Beliavsky wrote:
> ...

>
> I have wondered why certain statements are not allowed after the test
> in the Fortran one-line if statement. Often I want to write something like
>
> if (i > 0) if (x(i) > 0.0) print*,"i, x(i)=",i,x(i)
>

At first glance, it seems to be very simple & straightforward. In
specific, the draft has a plain text constraint that makes the above
invalid, and so removing the constraint shall normally be simple enough.


I also wonder if the evaluation order in this code is undefined:

$ cat all.f90 && gfc all.f90 && ./a.out

real :: x(10)
integer :: i

if ( all([i>0,x(i)>0])) print*,"i, x(i)=",i,x(i)

end

$

[Ev. Drikos]

On 03/06/2022 08:36, FortranFan wrote:
> ...

> By the way, I do not think the brackets around the inner expression are needed per the BNF in the standard, that is the following should work as well:
>
> if ( i > 0 ? x(i) > 0.0 ? .true. : .false. : .false. ) print *, "i, x(i) = ", i , x(i)
>

IMHO, additional parentheses are required according to his thread:
https://groups.google.com/g/comp.lang.fortran/c/q8UaefqOFpc/m/V2m-eji0AQAJ

FYI, there is a claim here that the upcoming conditional expressions
were finally found to be context sensitive:

https://github.com/drikosev/Fortran/commit/9a6095bb6b34f27131547a327a9c360f840f0d89

[Ev. Drikos]

On 03/06/2022 09:30, Ev. Drikos wrote:
> ...

>
>
> I also wonder if the evaluation order in this code is undefined:
>
> $ cat all.f90 && gfc all.f90 && ./a.out
>
>  real    :: x(10)
>  integer :: i
>
>  if ( all([i>0,x(i)>0])) print*,"i, x(i)=",i,x(i)
>
>  end
>
> $

Ok, this code is likely garbage as it crashed ie with:

integer :: i = -99999999

[Ron Shepard]

Yes, I contributed a few posts to that discussion. However, there was no
discussion there regarding the above question, namely allowing chained
if statements to evaluate short-circuiting logical expressions. The
fortran semantics are already correct for a single if statement, all
that would be necessary is to remove the current restriction to allow
them to chain together.

The modifiable aspect of the ?:: construct result looks to be useful,
but as shown above it can be verbose and confusing when nested for other
purposes. Allowing chained if statements seems to avoid both of those
problems. I wonder if that was discussed by the committee during any of
the short-circuit addition possibilities?

$.02 -Ron Shepard

[Ron Shepard]

On 6/2/22 8:40 PM, gah4 wrote:
> On Thursday, June 2, 2022 at 5:03:17 PM UTC-7, Ron Shepard wrote:
>
> (snip, someone wrote)
>
>>> if ( ( i > 0 ? ( if ( x(i) > 0.0 ) ? .true. : .false. ) : .false. ) ) print *, "i, x(i) = ", i , x(i)
>
>> One wonders, if they wanted to add something redundant to the language
>> to save typing a few extra characters, why didn't just add the above
>> fortran-like statement rather than incorporate the C-like syntax? Was
>> there any discussion about allowing the chained if statements?
>
> Well, for one, chained IF only works for the .AND. operation.

I'm not sure I follow this. In an if statement, any logical expression
can be used. In the short-circuit evaluation context, it would just keep
evaluating the expressions until a .false. is generated, and then it
would stop.

> Also, as well as I know it, the above could be written:
>
> if ( i > 0 ? ( x(i) > 0.0 ) : .false. ) print *, "i, x(i) = ", i , x(i)
>
> That is, the inner conditional operator isn't needed.

Yes you are using the advantage of the if statement that I'm talking
about. Still, something like

if ( i>0 ) if ( x(i)>0.0 ) print *, "i, x(i) = ", i , x(i)

seems to have some advantages, even with the ?:: operator available. To
my eye, that is the clearest way to accomplish that print statement of
all the suggestions. All that would be needed is to remove the current
restriction in the language.

$.02 -Ron Shepard

[Ron Shepard]

You must be using the gfortran option to initialize integer values.

To answer the original question, I do not think the order of evaluation
of the arguments to the all() intrinsic is defined. The compiler is free
to optimize any order or to reuse previously computed results.

$.02 -Ron Shepard

[gah4]

On Friday, June 3, 2022 at 7:52:40 AM UTC-7, Ron Shepard wrote:

(snip, I wrote)

> > Well, for one, chained IF only works for the .AND. operation.

> I'm not sure I follow this. In an if statement, any logical expression
> can be used. In the short-circuit evaluation context, it would just keep
> evaluating the expressions until a .false. is generated, and then it
> would stop.

You can (or could if it was allowed by the standard) convert:

if( A .AND. B .AND. C) ...

to

if(A) if(B) if(C) ...

You can convert:

if(A .OR. B .OR. C) ...

to

if(A) ...
if(B) ...
if(C) ...

at least when the ... is a GOTO, or some assignments.

[Robin Vowels]

On Friday, June 3, 2022 at 4:22:58 PM UTC+10, gah4 wrote:
> On Thursday, June 2, 2022 at 10:36:48 PM UTC-7, FortranFan wrote:
>
> (snip)
> > Apologies, I made an error by including an `IF` in the inner expression.
> Some years ago I used an ALGOL system that used IF THEN ELSE for
> its conditional operator:
>
> X:= IF A>B THEN A ELSE B;

That is standard Algol 60.
.

> I think I like the C notation, but others might like that one.
> I suspect it would cause problems in fixed form

.
Algol is free form source.
.

[Ron Shepard]

On 6/3/22 2:39 PM, gah4 wrote:
> On Friday, June 3, 2022 at 7:52:40 AM UTC-7, Ron Shepard wrote:

[...]

> You can convert:
>
> if(A .OR. B .OR. C) ...
>
> to
>
> if(A) ...
> if(B) ...
> if(C) ...
>
> at least when the ... is a GOTO, or some assignments.

The ?:: notation does not address this either, right? For this,
something like a short-circuiting OR is required that forces the
compiler to evaluate the expressions in left-to-right order with no
precomputation or out-of-order evaluation allowed. A short circuiting
ANY() operator with those same restrictions would also work.

However, the idea that the result of ?:: is modifiable is a new kind of
expression in fortran. None of these other possibilities would naturally
have that feature.

$.02 -Ron Shepard

[robertpa...@gmail.com]

Anything that can be done with short-circuit logical operators can
also be done using conditional expressions. The expression

A .OR. B .OR. C

where the .OR. operators are short-circuit operators is equivalent to

( A ? .TRUE. : ( B ? .TRUE. : C ) )

Left-to-right order is forced. No precomputation or out-of-order
execution is allowed.

[gah4]

On Saturday, June 4, 2022 at 8:01:48 AM UTC-7, Robert Corbett wrote:

(snip)

> Anything that can be done with short-circuit logical operators can
> also be done using conditional expressions. The expression

> A .OR. B .OR. C

> where the .OR. operators are short-circuit operators is equivalent to

> ( A ? .TRUE. : ( B ? .TRUE. : C ) )

Yes. But it is still ugly.

I suspect that there is desire not to change the old logical operators,
but there could be new ones.

Conditional expressions are nice and useful in many places.

Looking at that one, I have no idea what optimizing compilers
will do with it. I am pretty sure that for logical IF, compilers
rarely evaluate the logical expression (that is, store a .TRUE.
or .FALSE. somewhere). I would be less sure in this case.

> Left-to-right order is forced. No precomputation or out-of-order
> execution is allowed.

But that doesn't mean that we can't have new operators
that look nicer, and are easier to read.

[Louis Krupp]

I agree.

Fortran could borrow "conditional" operators from Burroughs/Unisys ALGOL:

"a .CAND. b" will not evaluate b if a is false, and "a. COR. b" will not
evaluate b if a is true.

Louis

[David Jones]

This would provide the opportunity to be more directional, with .LAND.
, .RAND, , .LOR. and .ROR. to indicate which side gets evaluated first.