• What results this legacy code should give?

    From Ev. Drikos@21:1/5 to All on Fri May 6 16:17:21 2022
    Hello,

    Currently, my attention is on Legacy code, DEC/VMS.
    IMOH, the results I see seem to be confusing. Maybe
    it's my fault or GNU Fortran after version 8 gives
    different results or what else?.

    Results from other compilers that support DEC/VMS
    extensions will be appreciated!

    Thanks,
    Ev. Drikos

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

    $ gfc -ffixed-form par.f && ./a.out
    parameters= 2.00000000
    $ gfc -ffree-form par.f && ./a.out
    parameters= 2.00000000
    $ gfc --version 2>&1 | head -n1
    GNU Fortran (GCC) 4.8.5

    $ gfortran8 -fdec -ffixed-form par.f && ./a.out
    parameters= 2.80259693E-45
    $ gfortran8 -fdec -ffree-form par.f && ./a.out
    parameters= 2.80259693E-45
    $ gfortran8 --version 2>&1 | head -n1
    GNU Fortran (GCC) 8.4.0

    $ cat par.f
    parameters = 2.0
    print *, 'parameters=', parameters
    end

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Arjen Markus@21:1/5 to Ev. Drikos on Fri May 6 07:45:39 2022
    On Friday, May 6, 2022 at 3:17:26 PM UTC+2, Ev. Drikos wrote:
    Hello,

    Currently, my attention is on Legacy code, DEC/VMS.
    IMOH, the results I see seem to be confusing. Maybe
    it's my fault or GNU Fortran after version 8 gives
    different results or what else?.

    Results from other compilers that support DEC/VMS
    extensions will be appreciated!

    Thanks,
    Ev. Drikos

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

    $ gfc -ffixed-form par.f && ./a.out
    parameters= 2.00000000
    $ gfc -ffree-form par.f && ./a.out
    parameters= 2.00000000
    $ gfc --version 2>&1 | head -n1
    GNU Fortran (GCC) 4.8.5

    $ gfortran8 -fdec -ffixed-form par.f && ./a.out
    parameters= 2.80259693E-45
    $ gfortran8 -fdec -ffree-form par.f && ./a.out
    parameters= 2.80259693E-45
    $ gfortran8 --version 2>&1 | head -n1
    GNU Fortran (GCC) 8.4.0

    $ cat par.f
    parameters = 2.0
    print *, 'parameters=', parameters
    end
    I compiled the program without -fdec and -ffixed-form and got this error:


    1 | parameters = 2.0
    | 1
    Warning: Legacy Extension: PARAMETER without '()' at (1)

    I think I understand - a bit - what is going on: your code is supposed to be fixed form. In fixed form spaces have no meaning. So the compiler (or better: some of the versions) probably interpret the first line as:

    PARAMETER S = 2.0

    So, a parameter "s" is defined and no variable "parameters". In that case you have an uninitialised variable and its value may be anything. Other versions may instead see this first line as defining a variable "parameters". Of course, this is a lot
    hineininterpretieren, but it might just fit :).

    Regards,

    Arjen

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John@21:1/5 to All on Fri May 6 08:54:42 2022
    You nailed it. The program is a DEC extension that allows for a PARAMETER statement to be indistinguishable from a variable declaration,
    so if you force standards compliance the problem goes away. That little example is a true classic. Of course, fixed-format has to start with six spaces, but because so many compilers allow DEC extensions it causes problems with just about everyone. As
    Arjen notes, it is only a problem with fixed format, and only a problem if the compiler supports the non-standard "PARAMETER S=2.0", as the standard requires
    "PARAMETER (S=2.0)"; so changing the name of the variable to something like PARMS or using free-format; or (hopefully) turning on standards conformance should solve it. You already solved the problem, but I was curious what some other compilers would
    do, and that was asked:buga.f:
    parameters = 2.0
    print *, 's=', s
    print *, 'parameters=', parameters
    end
    $ ifort buga.f
    $ ./a.out
    s= 2.000000
    parameters= 0.0000000E+00
    $ nvfortran buga.f
    $ ./a.out
    s= 2.000000
    parameters= 0.000000
    $ ifort buga.f
    $ ./a.out
    s= 2.000000
    parameters= 0.0000000E+00
    $ gfortran buga.f
    buga.f:1:16:
    1 | parameters = 2.0
    | 1
    Warning: Legacy Extension: PARAMETER without '()' at (1)
    $ ./a.out
    s= 2.00000000
    parameters= -5.24052938E+36
    $ gfortran -std=f2018 buga.f
    $ ./a.out
    s= -457056.000
    parameters= 2.00000000



    I sort of "like" this bug

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ron Shepard@21:1/5 to Ev. Drikos on Fri May 6 10:52:32 2022
    On 5/6/22 8:17 AM, Ev. Drikos wrote:

    Hello,

    Currently, my attention is on Legacy code, DEC/VMS.
    IMOH, the results I see seem to be confusing. Maybe
    it's my fault or GNU Fortran after version 8 gives
    different results or what else?.

    Results from other compilers that support DEC/VMS
    extensions will be appreciated!

    Thanks,
    Ev. Drikos

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

    $ gfc -ffixed-form par.f && ./a.out
      parameters=   2.00000000
    $ gfc -ffree-form par.f && ./a.out
      parameters=   2.00000000
    $ gfc --version 2>&1 | head  -n1
      GNU Fortran (GCC) 4.8.5

    Gfortran has always been an f90 compiler, so PARAMETERS is being
    interpreted as an implicitly typed real variable. The first line is an executable statement assigning the value of 2.0 to that variable. The
    code is interpreted the same way in both fixed form and free form.

    $ gfortran8 -fdec -ffixed-form par.f && ./a.out
      parameters=   2.80259693E-45
    $ gfortran8 -fdec -ffree-form par.f && ./a.out
      parameters=   2.80259693E-45
    $ gfortran8 --version 2>&1 | head  -n1
      GNU Fortran (GCC) 8.4.0

    Ignoring the lower case code for the moment, the f77 DEC extensions
    include two things, an ambiguous form of the parameter statement and
    also variables longer than 6 characters. Both of those extensions come
    into play here. the code is being interpreted as if it were

    parameter (S = 2.0)
    print *, 'parameters=', parameters

    The first line is the parameter declaration of the implicitly typed real variable S, which is then never referenced. The last line is printing
    the value of the implicitly typed real variable PARAMETERS, which is
    undefined.


    $ cat par.f
          parameters = 2.0
          print *, 'parameters=', parameters
          end

    Since this is ambiguous syntax, I do not know how other f77 compilers
    with VAX extensions would treat this code. I don't even know what a VAX
    fortran compiler would do with those extensions enabled. If those
    extensions are not enabled, then both lines should trigger compiler
    warnings about the long variable name PARAMETERS.

    As for the lower case code, that is allowed in f90+ and its behavior
    defined, but it was ambiguous in f77, and different compilers did
    different things. Some people argue that it was a language extension,
    others argue that it was part of the source code interpretation and
    processing that was explicitly excluded from consideration by the
    standard document.

    $.02 -Ron Shepard

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John@21:1/5 to All on Fri May 6 09:29:50 2022
    real :: parameters
    x=10
    parameters = 2.0
    print *, 's=', s
    print *, 'parameters=', parameters
    end

    I sort of "like" this bug

    For something that short to be so surprising is interesting; some compilers even have problems with the above. Note to self: do not start a variable name with "parameter". :>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to Ev. Drikos on Fri May 6 16:43:04 2022
    On Friday, May 6, 2022 at 11:17:26 PM UTC+10, Ev. Drikos wrote:
    Hello,

    Currently, my attention is on Legacy code, DEC/VMS.
    IMOH, the results I see seem to be confusing. Maybe
    it's my fault or GNU Fortran after version 8 gives
    different results or what else?.

    Results from other compilers that support DEC/VMS
    extensions will be appreciated!

    Thanks,
    Ev. Drikos

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

    $ gfc -ffixed-form par.f && ./a.out
    parameters= 2.00000000
    $ gfc -ffree-form par.f && ./a.out
    parameters= 2.00000000
    $ gfc --version 2>&1 | head -n1
    GNU Fortran (GCC) 4.8.5

    $ gfortran8 -fdec -ffixed-form par.f && ./a.out
    parameters= 2.80259693E-45
    $ gfortran8 -fdec -ffree-form par.f && ./a.out
    parameters= 2.80259693E-45
    $ gfortran8 --version 2>&1 | head -n1
    GNU Fortran (GCC) 8.4.0

    $ cat par.f
    parameters = 2.0
    print *, 'parameters=', parameters
    end

    Use IMPLICIT NONE

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ev. Drikos@21:1/5 to John on Sat May 7 14:41:37 2022
    On 06/05/2022 19:29, John wrote:

    real :: parameters
    x=10
    parameters = 2.0
    print *, 's=', s
    print *, 'parameters=', parameters
    end

    I sort of "like" this bug

    For something that short to be so surprising is interesting; some compilers even have problems with the above ...

    Implementing it in a LALR based parser is also tricky (gfortran is RD).

    All the replies were very helpful and here is what I've understood or
    better what a Fortran developer may expect or much better what finally
    worked in my case.

    With '-fno-dec' or '-ffree-form' I'd expect an assignment. Whereas, a
    legacy PARAMETER statement in fixed form could require ie '-fdec'. The
    option '-std=f2018' as supported by gfortran is of course good enough.


    Thanks everyone
    Ev. Drikos


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

    my own tokenization test with my own tool 'fcheck'
    (the script below run only the 1st example shown)


    miniserver:names suser$ ./test.sh
    ________________________
    correct = 1
    expected = 1
    unexpected = 0
    ________________________
    erroneous = 0
    expected = 0
    unexpected = 0
    ________________________
    miniserver:names suser$ cat par-1.f
    ! name-l PARAMETERS
    1 parameters=1.0
    2 end

    miniserver:names suser$ fcheck par-1.f -debug
    Line=00002,65588 label buffer=[1]
    Line=00002,66106 name-l buffer=[PARAMETERS]
    Line=00002,00061 = buffer=[=]
    Line=00002,65674 real-literal-constant buffer=[1.0]
    Line=00002,65800 ; buffer=[\r]
    Line=00003,65588 label buffer=[2]
    Line=00003,65570 END buffer=[END]
    Line=00003,65800 ; buffer=[\r]
    Line=00003,-0001 EOF buffer=[]
    miniserver:names suser$ fcheck -fdec par-1.f -debug
    Line=00002,65588 label buffer=[1]
    Line=00002,65673 PARAMETER buffer=[PARAMETER]
    Line=00002,66106 name-l buffer=[S]
    Line=00002,00061 = buffer=[=]
    Line=00002,65674 real-literal-constant buffer=[1.0]
    Line=00002,65800 ; buffer=[\r]
    Line=00003,65588 label buffer=[2]
    Line=00003,65570 END buffer=[END]
    Line=00003,65800 ; buffer=[\r]
    Line=00003,-0001 EOF buffer=[]
    miniserver:names suser$ fcheck -ffree-form -fdec par-1.f -debug
    Line=00002,65588 label buffer=[1]
    Line=00002,66106 name-l buffer=[PARAMETERS]
    Line=00002,00061 = buffer=[=]
    Line=00002,65674 real-literal-constant buffer=[1.0]
    Line=00002,65800 ; buffer=[\r]
    Line=00003,65588 label buffer=[2]
    Line=00003,65570 END buffer=[END]
    Line=00003,65800 ; buffer=[\r]
    Line=00004,-0001 EOF buffer=[]
    miniserver:names suser$

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Thomas Koenig@21:1/5 to Steve Lionel on Sat May 7 14:42:11 2022
    Steve Lionel <steve@seesignature.invalid> schrieb:
    On 5/6/2022 11:52 AM, Ron Shepard wrote:

    $ cat par.f
           parameters = 2.0
           print *, 'parameters=', parameters
           end

    Since this is ambiguous syntax, I do not know how other f77 compilers
    with VAX extensions would treat this code. I don't even know what a VAX
    fortran compiler would do with those extensions enabled. If those
    extensions are not enabled, then both lines should trigger compiler
    warnings about the long variable name PARAMETERS.

    The no-parenthesis PARAMETER syntax was part of the FORTRAN-77 draft
    right up until the published standard. DEC went ahead and implemented
    it, assuming it would be part of the final standard. When it wasn't,
    they had to support both. It is really more a lesson in the danger of fixed-form.

    ... and of not using IMPLICIT NONE, of course.

    Free form still has two important advantages: It is possible to use
    British English spelling, as in

    PROGRAMME MAIN

    and it is possible to group numbers, as in

    N = 123 234 567

    (although the latter could probably be added to free form, as
    well). Being able to write

    ELSE IF (A) = 23.

    is of lesser importance, I guess.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Steve Lionel@21:1/5 to Ron Shepard on Sat May 7 10:21:12 2022
    On 5/6/2022 11:52 AM, Ron Shepard wrote:

    $ cat par.f
           parameters = 2.0
           print *, 'parameters=', parameters
           end

    Since this is ambiguous syntax, I do not know how other f77 compilers
    with VAX extensions would treat this code. I don't even know what a VAX fortran compiler would do with those extensions enabled. If those
    extensions are not enabled, then both lines should trigger compiler
    warnings about the long variable name PARAMETERS.

    The no-parenthesis PARAMETER syntax was part of the FORTRAN-77 draft
    right up until the published standard. DEC went ahead and implemented
    it, assuming it would be part of the final standard. When it wasn't,
    they had to support both. It is really more a lesson in the danger of fixed-form.

    --
    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 Ron Shepard@21:1/5 to Thomas Koenig on Sat May 7 11:21:34 2022
    On 5/7/22 9:42 AM, Thomas Koenig wrote:
    Steve Lionel <steve@seesignature.invalid> schrieb:
    On 5/6/2022 11:52 AM, Ron Shepard wrote:

    $ cat par.f
           parameters = 2.0
           print *, 'parameters=', parameters
           end

    Since this is ambiguous syntax, I do not know how other f77 compilers
    with VAX extensions would treat this code. I don't even know what a VAX
    fortran compiler would do with those extensions enabled. If those
    extensions are not enabled, then both lines should trigger compiler
    warnings about the long variable name PARAMETERS.

    The no-parenthesis PARAMETER syntax was part of the FORTRAN-77 draft
    right up until the published standard. DEC went ahead and implemented
    it, assuming it would be part of the final standard. When it wasn't,
    they had to support both. It is really more a lesson in the danger of
    fixed-form.

    ... and of not using IMPLICIT NONE, of course.

    This has been mentioned a couple of times now in this thread, and just
    as a reminder IMPLICIT NONE was not part of standard fortran until f90.
    So if one wanted to write standard code in the 1980s, this was not an
    option.

    On the other hand, as I've stated before, if you wanted to do something
    useful and nontrivial, or if you were concerned about portability of the
    code, you were almost required to use extensions to the language. F77 by
    itself was just missing too much functionality. Vendors at that time
    were happy with that situation because it allowed them to lock in their customers who relied on their extensions. IMPLICIT NONE was one of those
    useful extensions -- portable but nonstandard in that case.


    Free form still has two important advantages: It is possible to use
    British English spelling, as in

    PROGRAMME MAIN

    and it is possible to group numbers, as in

    N = 123 234 567

    This is actually something that I miss in the language. In f77, I would routinely specify real constants such as pi with 30 to 40 digits, just
    to make it easier in the future if I ever wanted to change the code to
    some kind of extended precision. When I started this, I typed in the
    digits by hand, so it was handy to put some spaces in the constants
    every 3 or every 5 digits to make them easier to verify and for a future programmer to read.

    $.02 -Ron Shepard

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Gary Scott@21:1/5 to Ron Shepard on Sat May 7 15:14:08 2022
    On 5/7/2022 11:21 AM, Ron Shepard wrote:
    On 5/7/22 9:42 AM, Thomas Koenig wrote:
    Steve Lionel <steve@seesignature.invalid> schrieb:
    On 5/6/2022 11:52 AM, Ron Shepard wrote:

    $ cat par.f
            parameters = 2.0
            print *, 'parameters=', parameters
            end

    Since this is ambiguous syntax, I do not know how other f77 compilers
    with VAX extensions would treat this code. I don't even know what a VAX >>>> fortran compiler would do with those extensions enabled. If those
    extensions are not enabled, then both lines should trigger compiler
    warnings about the long variable name PARAMETERS.

    The no-parenthesis PARAMETER syntax was part of the FORTRAN-77 draft
    right up until the published standard. DEC went ahead and implemented
    it, assuming it would be part of the final standard. When it wasn't,
    they had to support both. It is really more a lesson in the danger of
    fixed-form.

    ... and of not using IMPLICIT NONE, of course.

    This has been mentioned a couple of times now in this thread, and just
    as a reminder IMPLICIT NONE was not part of standard fortran until f90.
    So if one wanted to write standard code in the 1980s, this was not an
    option.

    On the other hand, as I've stated before, if you wanted to do something useful and nontrivial, or if you were concerned about portability of the code, you were almost required to use extensions to the language. F77 by itself was just missing too much functionality. Vendors at that time
    were happy with that situation because it allowed them to lock in their customers who relied on their extensions. IMPLICIT NONE was one of those useful extensions -- portable but nonstandard in that case.

    But we still don't have a lot of those necessary extensions, still
    having to use extensions. Like mechanisms to access shared memory areas
    across processes and hardware. Ability to create and/or initiate other processes and threads. All of those critical things require extensions
    or OS API calls or 3rd party API calls. There's just so much missing
    still. Coarrays largely miss the point of greatest need.

    snip

    $.02 -Ron Shepard

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to Ron Shepard on Sat May 7 12:56:47 2022
    On Saturday, May 7, 2022 at 9:21:39 AM UTC-7, Ron Shepard wrote:

    (snip)

    ... and of not using IMPLICIT NONE, of course.

    This has been mentioned a couple of times now in this thread, and just
    as a reminder IMPLICIT NONE was not part of standard fortran until f90.
    So if one wanted to write standard code in the 1980s, this was not an
    option.

    I remember stories about some using:

    IMPLICIT LOGICAL (A-$)

    and then the compiler (unless it has other extensions) will complain
    about the use of LOGICAL variables.

    Or printing them would give a T or F, and not a number left over in
    the variable.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From James Van Buskirk@21:1/5 to Thomas Koenig on Sat May 7 20:25:12 2022
    "Thomas Koenig" wrote in message news:t56tfm$u2s$1@newsreader4.netcologne.de...

    I used to use

    IMPLICT CHARACTER*1 (A-Z)

    which caught many, if not all, errors. Inventing a variable name
    in a subroutine argument was not caught this way, for example.

    Wouldn't
    IMPLICIT CHARACTER*(*) (A-Z)
    have caught a couple more errors?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Thomas Koenig@21:1/5 to James Van Buskirk on Sun May 8 07:37:44 2022
    James Van Buskirk <not_valid@comcast.net> schrieb:
    "Thomas Koenig" wrote in message news:t56tfm$u2s$1@newsreader4.netcologne.de...

    I used to use

    IMPLICT CHARACTER*1 (A-Z)

    which caught many, if not all, errors. Inventing a variable name
    in a subroutine argument was not caught this way, for example.

    Wouldn't
    IMPLICIT CHARACTER*(*) (A-Z)
    have caught a couple more errors?

    Possibly, but the people who wrote up the advice at the time
    didn't think of it, and neither did I :-)

    After I moved my development to UNIX-based Fortran compilers which
    supported IMPLICIT NONE, the point became moot. f2c also supports
    this, IIRC.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From FortranFan@21:1/5 to Ron Shepard on Sun May 8 06:11:28 2022
    On Saturday, May 7, 2022 at 12:21:39 PM UTC-4, Ron Shepard wrote:

    .. a reminder IMPLICIT NONE was not part of standard fortran until f90.
    So if one wanted to write standard code in the 1980s, this was not an
    option ..

    And that remains yet another unfortunate event in the history of Fortran.

    ANSI X3.9-1978 document toward FORTRAN 77 was approved by ANSI on April 3, 1978 that became the de facto standard reference for FORTRAN 77.

    Now consider MILITARY STANDARD 1753 FORTRAN, US DoD Supplement To American National Standard X3.9-1978 dated November 9, 1978, months later:
    https://wg5-fortran.org/ARCHIVE/mil_std_1753.html

    which introduced `IMPLICIT NONE` that was recognized as useful by many users at the time and which was then implemented by many compilers as an extension that became popular enough to make it into Fortran 90 revision, 13 years later.

    If only `IMPLICIT NONE` had made into ANSI X3.9-1978 document itself, clearly the notion of `IMPLICIT NONE` must have been circulating given its appearance just months later in the MIL-STD 1753 document!

    And if only Fortran 90 had instead made `IMPLICIT NONE` the default (the semantics of explicit everything), at least for all the new program scopes it introduced such as INTERFACEs and MODULEs! That is, as compromise at least given all the crazy battles
    that supposedly characterized Fortran standard revision during the 1980s :-(

    That was some serious failure of imagination back then which handicapped the practice of Fortran.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ron Shepard@21:1/5 to Thomas Koenig on Sun May 8 12:16:01 2022
    On 5/8/22 2:37 AM, Thomas Koenig wrote:
    James Van Buskirk <not_valid@comcast.net> schrieb:
    "Thomas Koenig" wrote in message
    news:t56tfm$u2s$1@newsreader4.netcologne.de...

    I used to use

    IMPLICT CHARACTER*1 (A-Z)

    which caught many, if not all, errors. Inventing a variable name
    in a subroutine argument was not caught this way, for example.

    Wouldn't
    IMPLICIT CHARACTER*(*) (A-Z)
    have caught a couple more errors?

    Possibly, but the people who wrote up the advice at the time
    didn't think of it, and neither did I :-)

    After I moved my development to UNIX-based Fortran compilers which
    supported IMPLICIT NONE, the point became moot. f2c also supports
    this, IIRC.

    i also used implicit character declarations in my codes for a while as a work-around for the lack of implicit none in f77. Then something strange happened on a compiler. I was doing some bit-packing with shift(),
    and(), or(), and so on (I forget now exactly which set of operators this compiler supported), and the compiler treated the intermediate results
    as the default character. This was an intermediate within an expression,
    not an implicitly declared variable. You could use basically any other
    type in the bit operators, integers, logicals, reals, they were all
    allowed and they were all treated as just a string of bits, but
    character arguments were not allowed. So a little piece of code that
    worked successfully on a dozen other compilers with the implicit
    character declaration raised an error on this particular compiler. I
    think implicit none happened to work alright, so I switched to that and everything was fine. I was already using nonstandard extensions in that
    little subroutine anyway, so it wasn't a big deal at the time. But it
    did show me how important it was to have all those little details
    specified in the standard document. F90 compilers were still about a
    decade away at that time.

    $.02 -Ron Shepard

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ron Shepard@21:1/5 to FortranFan on Sun May 8 13:27:29 2022
    On 5/8/22 8:11 AM, FortranFan wrote:
    On Saturday, May 7, 2022 at 12:21:39 PM UTC-4, Ron Shepard wrote:

    .. a reminder IMPLICIT NONE was not part of standard fortran until f90.
    So if one wanted to write standard code in the 1980s, this was not an
    option ..

    And that remains yet another unfortunate event in the history of Fortran.

    ANSI X3.9-1978 document toward FORTRAN 77 was approved by ANSI on April 3, 1978 that became the de facto standard reference for FORTRAN 77.

    Now consider MILITARY STANDARD 1753 FORTRAN, US DoD Supplement To American National Standard X3.9-1978 dated November 9, 1978, months later:
    https://wg5-fortran.org/ARCHIVE/mil_std_1753.html

    which introduced `IMPLICIT NONE` that was recognized as useful by many users at the time and which was then implemented by many compilers as an extension that became popular enough to make it into Fortran 90 revision, 13 years later.

    Yes, there were several useful extensions that were in the MIL-STD
    document, including IMPLICIT NONE, INCLUDE, and the set of bit operators
    that were all eventually included in f90.

    I think most programmers were expecting a revision to the f77 standard
    in the early 1980s that would have included the MIL-STD features plus
    maybe a few more things that did not quite make it into f77.
    Asynchronous I/O and conditional compilation (a preprocessor) were at
    the top of my most-wanted list at that time. Then in the mid 1980s there
    would have been a more substantial update of the language, perhaps
    free-form source (to facilitate preprocessor use) would have made it at
    that time -- I think those things, along with array syntax, were
    included in the early fortran 8x drafts.

    But all that never happened.

    I continued to use vendor extensions for asynchronous i/o, and I wrote
    my own conditional compilation utility (in fortran, of course).

    In hindsight, the major benefit of f90 was modules and explicit
    interfaces. I do not know when that functionality was adopted in the f8x
    saga.


    If only `IMPLICIT NONE` had made into ANSI X3.9-1978 document itself, clearly the notion of `IMPLICIT NONE` must have been circulating given its appearance just months later in the MIL-STD 1753 document!

    Yes, by the mid 1970s, well before f77 was adopted, IMPLICIT NONE was a
    common f66 extension, and it was frequently used by programmers. I do
    not understand why it did not make it into the f77 document.


    And if only Fortran 90 had instead made `IMPLICIT NONE` the default (the semantics of explicit everything), at least for all the new program scopes it introduced such as INTERFACEs and MODULEs! That is, as compromise at least given all the crazy
    battles that supposedly characterized Fortran standard revision during the 1980s :-(

    One proposal was to make the default different for fixed- and free-form
    source. The arguments that won the day were the idea of keeping the
    semantics the same between fixed- and free-form source and to maintain
    backward compatibility. For me personally, I don't mind typing that line
    in my codes, but I know that some programmers do dislike it. On the
    other hand, there are some programmers who prefer implicit typing, so
    even if IMPLICIT NONE had become the default, they would have continued
    to use IMPLICIT REAL(A-H,O-Z),INTEGER(I-N) statements and to continue
    that practice.


    That was some serious failure of imagination back then which handicapped the practice of Fortran.

    I think the main problem in the 1980s was that the vendors simply did
    not want a new standard, for a variety of reasons. Both of the leading
    vendors at the time, IBM and DEC, lobbied heavily against revising the language, along with some smaller vendors such as CONVEX. At least
    within ANSI, the vendors had more sway than the users of the language.
    It was the ISO committee that stepped up and basically saved the
    language from extinction. ISO approved the new language revision BEFORE
    the ANSI committee did, something that was unprecedented. That kept
    fortran alive, barely, for another decade. Then, I think it was the
    development of gfortran that saved it a decade later. Almost certainly,
    without ISO f90 and without a free open-source compiler like gfortran,
    fortran would not have survived to the present day.

    $.02 -Ron Shepard

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John@21:1/5 to All on Sun May 8 12:20:27 2022
    I agree, although I think g95 saved it, then gfortran sustained it.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Phillip Helbig (undress to reply@21:1/5 to nospam@nowhere.org on Sun May 15 10:04:23 2022
    In article <i0xdK.9778$gc62.7492@fx45.iad>, Ron Shepard
    <nospam@nowhere.org> writes:

    This has been mentioned a couple of times now in this thread, and just
    as a reminder IMPLICIT NONE was not part of standard fortran until f90.
    So if one wanted to write standard code in the 1980s, this was not an
    option.

    But IMPLICIT LOGICAL was almost as good.

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