• Fortran standards committee approves conditional expressions

    From Robin Vowels@21:1/5 to Beliavsky on Wed Jul 7 21:34:45 2021
    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)
  • From gah4@21:1/5 to dpb on Thu Jul 8 01:26:03 2021
    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)
  • From pehache@21:1/5 to All on Thu Jul 8 13:41:59 2021
    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)
  • From Thomas Koenig@21:1/5 to pehache on Thu Jul 8 14:22:56 2021
    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)
  • From pehache@21:1/5 to All on Thu Jul 8 19:25:53 2021
    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)
  • From gah4@21:1/5 to someone on Thu Jul 8 18:38:24 2021
    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)
  • From Ron Shepard@21:1/5 to All on Fri Jul 9 02:13:20 2021
    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)
  • From gah4@21:1/5 to Ron Shepard on Fri Jul 9 00:41:46 2021
    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)
  • From Ev. Drikos@21:1/5 to pehache on Fri Jul 9 10:43:45 2021
    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)
  • From Ev. Drikos@21:1/5 to Ev. Drikos on Fri Jul 9 11:33:43 2021
    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)
  • From Ron Shepard@21:1/5 to All on Fri Jul 9 15:01:24 2021
    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)
  • From gah4@21:1/5 to Ron Shepard on Fri Jul 9 18:30:49 2021
    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)
  • From rbader@21:1/5 to Steve Lionel on Sat Jul 10 11:18:33 2021
    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)
  • From JCampbell@21:1/5 to Thomas Koenig on Sat Jul 10 21:19:51 2021
    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)
  • From gah4@21:1/5 to JCampbell on Sun Jul 11 12:26:41 2021
    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)
  • From Ron Shepard@21:1/5 to All on Mon Jul 12 11:26:01 2021
    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)
  • From Lynn McGuire@21:1/5 to Robin Vowels on Mon Jul 12 15:50:53 2021
    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)
  • From gah4@21:1/5 to All on Mon Jul 12 13:43:28 2021
    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)
  • From gah4@21:1/5 to someone on Mon Jul 12 16:24:44 2021
    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)
  • From Thomas Koenig@21:1/5 to gah4@u.washington.edu on Tue Jul 13 05:09:39 2021
    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)
  • From Phillip Helbig---undress to reply@21:1/5 to tkoenig@netcologne.de on Tue Jul 13 07:33:01 2021
    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)
  • From Lynn McGuire@21:1/5 to Phillip Helbig---undress to reply on Tue Jul 27 15:01:18 2021
    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)
  • From Dominik Gronkiewicz@21:1/5 to All on Thu Sep 2 03:41:33 2021
    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)
  • From spectrum@21:1/5 to Dominik on Thu Sep 2 05:58:49 2021
    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)
  • From FortranFan@21:1/5 to spectrum on Fri Sep 3 07:53:41 2021
    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)
  • From JRR@21:1/5 to All on Sat Sep 4 21:53:51 2021
    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)
  • From gah4@21:1/5 to gro...@gmail.com on Sat Sep 4 23:26:11 2021
    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)
  • From Thomas Koenig@21:1/5 to JRR on Sun Sep 5 09:44:45 2021
    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)
  • From FortranFan@21:1/5 to Thomas Koenig on Sun Sep 5 18:09:31 2021
    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)
  • From Ron Shepard@21:1/5 to JRR on Mon Sep 6 16:31:54 2021
    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)
  • From Ev. Drikos@21:1/5 to Ron Shepard on Wed Sep 8 15:22:27 2021
    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)
  • From Ron Shepard@21:1/5 to Ev. Drikos on Wed Sep 8 12:05:48 2021
    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)
  • From Thomas Koenig@21:1/5 to Ron Shepard on Wed Sep 8 19:51:13 2021
    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)
  • From Ev. Drikos@21:1/5 to Ron Shepard on Fri Sep 10 14:56:32 2021
    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)
  • From Thomas Koenig@21:1/5 to Ev. Drikos on Fri Sep 10 15:03:33 2021
    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)
  • From FortranFan@21:1/5 to Thomas Koenig on Fri Sep 10 11:04:28 2021
    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)
  • From gah4@21:1/5 to FortranFan on Fri Sep 10 12:08:07 2021
    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)
  • From Ev. Drikos@21:1/5 to All on Sat Sep 11 05:39:29 2021
    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)
  • From Dominik Gronkiewicz@21:1/5 to All on Thu Sep 30 05:40:26 2021
    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)
  • From FortranFan@21:1/5 to gro...@gmail.com on Thu Sep 30 11:37:30 2021
    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)
  • From Robin Vowels@21:1/5 to All on Sun Oct 31 16:59:04 2021
    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)