On 6/1/22 10:24 AM, Ron Shepard wrote:
> 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.

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

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)

On 6/2/22 12:54 PM, FortranFan wrote:
> 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)

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

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

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.

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.

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.

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

$

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

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

On 6/2/22 8:40 PM, FortranFan wrote:
> 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

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

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

On 6/3/22 8:48 AM, Ev. Drikos wrote:
> 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

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

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.

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.
..
> where blanks
> (or lack of) are not significant. IF, THEN, and ELSE are
> already reserved words in ALGOL.

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

On Saturday, June 4, 2022 at 4:50:47 AM UTC-7, Ron Shepard wrote:
> 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

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.

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.

On 6/4/2022 2:59 PM, gah4 wrote:
> 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.
>
>

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

Louis Krupp wrote:

> On 6/4/2022 2:59 PM, gah4 wrote:
> > 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.
> >
> >
>
> 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

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