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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

"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)

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)

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)

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)

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)

I agree, although I think g95 saved it, then gfortran sustained it.

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

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)