• f2c updated to handle Fortran structures

    From Lynn McGuire@21:1/5 to All on Thu May 26 16:35:16 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to Lynn McGuire on Thu May 26 21:38:39 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to Lynn McGuire on Fri May 27 01:19:24 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Beliavsky@21:1/5 to Lynn McGuire on Fri May 27 12:33:57 2022
    On Thursday, May 26, 2022 at 5:35:21 PM UTC-4, 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.

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

    Thanks,
    Lynn

    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;

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lynn McGuire@21:1/5 to Robin Vowels on Fri May 27 16:14:28 2022
    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.

    Lynn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From CyrMag@21:1/5 to Lynn McGuire on Fri May 27 17:00:22 2022
    On Thursday, May 26, 2022 at 4:35:21 PM UTC-5, 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.

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

    Thanks,
    Lynn

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to Lynn McGuire on Mon May 30 06:15:30 2022
    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.
    .
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lynn McGuire@21:1/5 to Robin Vowels on Mon May 30 23:07:37 2022
    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.
    .
    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.

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Daniel Feenberg@21:1/5 to Lynn McGuire on Tue May 31 04:30:31 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Gary Scott@21:1/5 to Lynn McGuire on Tue May 31 09:40:27 2022
    On 5/30/2022 11:07 PM, 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.
    .
    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.

    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

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lynn McGuire@21:1/5 to Gary Scott on Tue May 31 13:12:58 2022
    On 5/31/2022 9:40 AM, Gary Scott wrote:
    On 5/30/2022 11:07 PM, 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.
    .
    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.

    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

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

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

    Lynn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lynn McGuire@21:1/5 to Daniel Feenberg on Tue May 31 13:27:43 2022
    On 5/31/2022 6:30 AM, Daniel Feenberg wrote:
    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

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Thomas Koenig@21:1/5 to Lynn McGuire on Tue May 31 20:02:47 2022
    Lynn McGuire <lynnmcguire5@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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to Thomas Koenig on Tue May 31 14:36:41 2022
    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);

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lynn McGuire@21:1/5 to Thomas Koenig on Tue May 31 17:04:45 2022
    On 5/31/2022 3:02 PM, Thomas Koenig wrote:
    Lynn McGuire <lynnmcguire5@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.

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Gary Scott@21:1/5 to Lynn McGuire on Wed Jun 1 09:13:43 2022
    On 5/31/2022 1:12 PM, Lynn McGuire wrote:
    On 5/31/2022 9:40 AM, Gary Scott wrote:
    On 5/30/2022 11:07 PM, 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.
    .
    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.

    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

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

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

    Lynn
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ron Shepard@21:1/5 to Lynn McGuire on Wed Jun 1 10:24:30 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lynn McGuire@21:1/5 to Ron Shepard on Wed Jun 1 13:07:08 2022
    On 6/1/2022 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.

    $.02 -Ron Shepard

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lynn McGuire@21:1/5 to Gary Scott on Wed Jun 1 13:01:42 2022
    On 6/1/2022 9:13 AM, Gary Scott wrote:
    On 5/31/2022 1:12 PM, Lynn McGuire wrote:
    On 5/31/2022 9:40 AM, Gary Scott wrote:
    On 5/30/2022 11:07 PM, 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.
    .
    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.

    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

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

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

    Lynn
    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.

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to Lynn McGuire on Wed Jun 1 12:46:29 2022
    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!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to Ron Shepard on Wed Jun 1 12:38:13 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Thomas Koenig@21:1/5 to gah4@u.washington.edu on Wed Jun 1 20:19:22 2022
    gah4 <gah4@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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Beliavsky@21:1/5 to Thomas Koenig on Wed Jun 1 18:31:15 2022
    On Wednesday, June 1, 2022 at 4:19:26 PM UTC-4, Thomas Koenig wrote:
    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.

    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)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to Beliavsky on Wed Jun 1 18:58:26 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to Beliavsky on Wed Jun 1 22:34:49 2022
    On Thursday, June 2, 2022 at 11:31:17 AM UTC+10, Beliavsky wrote:
    On Wednesday, June 1, 2022 at 4:19:26 PM UTC-4, Thomas Koenig wrote:
    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.
    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)
    .
    Try
    if (i > 0) then ; if (x(i) > 0.0) print etc ; end if

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ron Shepard@21:1/5 to Ron Shepard on Thu Jun 2 09:24:05 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From FortranFan@21:1/5 to Beliavsky on Thu Jun 2 10:54:52 2022
    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)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ron Shepard@21:1/5 to FortranFan on Thu Jun 2 19:03:12 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From FortranFan@21:1/5 to Ron Shepard on Thu Jun 2 18:40:01 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to someone on Thu Jun 2 18:40:12 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From FortranFan@21:1/5 to FortranFan on Thu Jun 2 22:36:46 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ev. Drikos@21:1/5 to Beliavsky on Fri Jun 3 09:30:47 2022
    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

    $

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to FortranFan on Thu Jun 2 23:22:56 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ev. Drikos@21:1/5 to FortranFan on Fri Jun 3 10:52:34 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ev. Drikos@21:1/5 to Ev. Drikos on Fri Jun 3 16:48:55 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ron Shepard@21:1/5 to Ev. Drikos on Fri Jun 3 10:02:26 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ron Shepard@21:1/5 to FortranFan on Fri Jun 3 09:35:08 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ron Shepard@21:1/5 to All on Fri Jun 3 09:52:36 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to All on Fri Jun 3 12:39:08 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to All on Fri Jun 3 22:05:57 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ron Shepard@21:1/5 to All on Sat Jun 4 06:50:42 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From robertpaulcorbett@gmail.com@21:1/5 to Ron Shepard on Sat Jun 4 08:01:46 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to Robert Corbett on Sat Jun 4 13:59:43 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Louis Krupp@21:1/5 to All on Mon Jun 6 14:14:53 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Jones@21:1/5 to Louis Krupp on Tue Jun 7 19:22:32 2022
    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.

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