Some ideas for Fortran, from a newbies perspective

[Evert Provoost]

Dear reader,

As far as I can tell the 'call for proposals' for Fortran 202x is closed, but if
small(-ish) ideas are still welcome:

The following is the perspective of someone first learning Fortran. However, in
my personal experience beginners tend to notice quirks and some possible
improvements easier. This of course also means that some of these proposals
might be naive or even borderline ignorance (in which case: please do call me
out for it).

Anyway, here are a couple of ideas for the next (or later) Fortran standard:



1) Add a 'version specifier' (and make 'IMPLICIT NONE' the default).

The 'version specifier' would be a line at the start of a file eg.

FORTRAN 2018

PROGRAM hello
[...]

This way a compiler doesn't have to guess whether a file is for instance in
fixed or free format. This would also allow standards to include changes that
would break very old code but not modern practice. Eg. `IMPLICIT NONE` becoming
the default. A compiler could also give warnings about better ways to do things
when using older style constructs, etc.



2) Adding matrix literals.

This is mostly a quality of life thing, but something like

INTEGER, DIMENSION(2, 2) :: A = [1, 2; 3, 4]

representing the matrix
/ 1 2 \
\ 3 4 /

is, to me, a lot more readable than

INTEGER, DIMENSION(2, 2) :: A = TRANSPOSE(RESHAPE([1, 2, 3, 4], [2, 2]))

This could even be extended to more complex arrays by, for instance, repeating
semicolons, eg.

INTEGER, DIMENSION(2, 2, 2) :: B = [1, 2; 3, 4;; 5, 6; 7, 8]

One issue with this syntax is of course that the values are given row major,
which is different from the memory layout of Fortran an thus also the way
RESHAPE works.

Alternatively [1, 2; 3, 4] could represent
/ 1 3 \
\ 2 4 /



3) Extending the format syntax to also allow variable width numbers and string
literals in READs.

This would, as far as I can tell, make READ as, and even more, useful as C's
scanf.

One way of doing this is to add a range option to the width in an edit
descriptor by adding a (lo,hi) syntax. For instance, a integer between 1 and 9
digits wide could be specified as I(1,9). By leaving out the upper limit, thus
writing: I(1,), any integer would be accepted.

A string literal in the format of a READ would simply be interpreted as a
separator which has to be present.

A concrete example would be:

READ (*, '(I4, "-", I(1,2), "-", I(1,2))') YEAR, MONTH, DAY

Which would accept '2019-6-03' but not, for instance, '19-006-', '2019--08-06'
or '2019-06*07'.

Cases like '(I(1,), "00")' do pose an issue as to how these should be
interpreted.



Sincerely,
Evert Provoost

[Nasser M. Abbasi]

On 7/22/2019 7:55 AM, Evert Provoost wrote:

>
> 1) make 'IMPLICIT NONE' the default).

I would think that this will break lots of old Fortran code.

--Nasser

[dpb]

On 7/22/2019 7:55 AM, Evert Provoost wrote:

...

> 1) Add a 'version specifier' (and make 'IMPLICIT NONE' the default).
>
> The 'version specifier' would be a line at the start of a file eg.
>

...

Most(?) compilers have a -fimplicit-none user flag already altho that
isn't in the Standard one can accomplish the effect with those compilers
that do.

Actually changing the Standard would, as another already noted, seem
unlikely to be going to happen for the compatibility issues it creates
to do so.

--

[FortranFan]

On Monday, July 22, 2019 at 10:06:34 AM UTC-4, Nasser M. Abbasi wrote:

>..

>
> I would think that this will break lots of old Fortran code.

> ..

Fortran standard can consider making IMPLICIT NONE the default in free-form source.

Clearly the language imposes differences on coders and processors when it comes to the two source forms: the following standard-conforming code in fixed-form is not so in free-form due to the semantics and syntax of continuation lines and comments:

--- begin example ---
character(len=*), parameter :: s =
c The ampersand on the following line is in column 6
& "Hello World!"
print *, s
end
--- end example ---

So why not build on intricacies such as above with the most important aspect of all which is IMPLICIT NONE?

The benefit of IMPLICIT NONE as the default in free-form source far outweigh any consequences of broken old code.

[Richard Weed]

I think having IMPLICIT NONE as a default for free-form code would be a good idea. A couple of small changes I would like to see though is to allow it to precede USE statements and maybe inherited from modules. something like
PUBLIC :(IMPLICIT NONE) perhaps. As to breaking old code, I think maybe its time to start giving more emphasis to the new features in Fortran than slavishly trying to support 60 year old code. Yes, the ability to compile legacy code is one of Fortran's great strengths. Unfortunately, I think its also one of the things that might be its eventual downfall. The perception will persist that Fortan is only good for compiling old code and thats the only legitimate reason to keep it alive. I personally would love to see someone "fork" Fortran and remove all support for everything that has been officially deleted or declared obsolete (like the F compiler project tried to do) throught the F2018 standard. Maybe even call it something other than Fortran :>) if thats what it takes to get more people to try it. I also think that would be an opportunity for someone to develop a suite of refactoring tools (maybe based on AI or deep learning) that can translate old sphagetti code into something more structured and modern looking.

[Lynn McGuire]

Clive Page with Cobalt Blue used to sell a two products called FOR_STUDY
and FOR_STRUCT that would structure Fortran 77 code. I own a copy but I
have never used it.

Lynn

[steve kargl]

Evert Provoost wrote:

>
> 1) Add a 'version specifier' (and make 'IMPLICIT NONE' the default).
>

The ship for IMPLICIT NONE as default sailed 29 years ago. If anyone
thinks that all free-form source code uses IMPLICIT NONE, you need
to spend sometime triaging bugs for gfortran. Changing the default
will simply break too much code. If J3 were to do anything alongs of
making IMPLICIT NONE the default, I would rather that J3 drop fixed
form code completely from the standard.

---
steve

[ga...@u.washington.edu]

The OP asked for a version specifier statement.

It would be possible to have a statement specifying that
IMPLICIT NONE was the default. One could, for example, have
a DEFAULT statement that would specify some things as default,
when they otherwise weren't. Then you could have

DEFAULT IMPLICIT NONE

which would make it default for that program. But that is less
convenient than just putting in the statement.

There might be some things, though, for which a program specific
default change would be useful.

[Evert Provoost]

As gah4 noted the main proposal was to add a version specifier statement.

The way I thought of it was like gfortran's -std flag. However if we require all
valid, say, Fortran 2021 programs to start with `FORTRAN 2021`. This way we can,
as a welcome example, make IMPLICIT NONE the default (or even the only available
option) without breaking old code as that code wouldn't start with

FORTRAN 2021

and is thus written in an older version of Fortran. This way writing a new Fortran compiler can also become somewhat easier as 'supporting old versions' isn't part of the standard any more, however compilers can choose (and most will
probably do so) to keep supporting older Fortran versions.

The main goal here is to keep both the ones that want full backwards
compatibility and those that want a leaner Fortran happy whilst also (somewhat)
easing compiler development: by simply stating the standard that is being used.

(See the first two comments under Miscellaneous on page 18 of N2147:
https://isotc.iso.org/livelink/livelink?func=ll&objId=19530634&objAction=Open&viewType=1)



For those coming to the discussion at a later time: do note that this is only
one of three ideas. (2) is a proposal for a more general syntax for array
literals and (3) is an extension to edit descriptors in READ statements.

[robin....@gmail.com]

On Monday, July 22, 2019 at 10:55:03 PM UTC+10, Evert Provoost wrote:
> Dear reader,
>
> As far as I can tell the 'call for proposals' for Fortran 202x is closed, but if
> small(-ish) ideas are still welcome:
>
> The following is the perspective of someone first learning Fortran. However, in
> my personal experience beginners tend to notice quirks and some possible
> improvements easier. This of course also means that some of these proposals
> might be naive or even borderline ignorance (in which case: please do call me
> out for it).
>
> Anyway, here are a couple of ideas for the next (or later) Fortran standard:
>
>
>
> 1) Add a 'version specifier' (and make 'IMPLICIT NONE' the default).
>
> The 'version specifier' would be a line at the start of a file eg.
>
> FORTRAN 2018
>
> PROGRAM hello
> [...]
>
> This way a compiler doesn't have to guess whether a file is for instance in
> fixed or free format.

This is usually done automatically with the file name suffix,
namely, F and F77 for fixed format, and F90 for free format.

> This would also allow standards to include changes that
> would break very old code but not modern practice. Eg. `IMPLICIT NONE` becoming
> the default. A compiler could also give warnings about better ways to do things
> when using older style constructs, etc.
>
>
>
> 2) Adding matrix literals.
>
> This is mostly a quality of life thing, but something like
>
> INTEGER, DIMENSION(2, 2) :: A = [1, 2; 3, 4]
>
> representing the matrix
> / 1 2 \
> \ 3 4 /

Good one.

> is, to me, a lot more readable than
>
> INTEGER, DIMENSION(2, 2) :: A = TRANSPOSE(RESHAPE([1, 2, 3, 4], [2, 2]))
>
> This could even be extended to more complex arrays by, for instance, repeating
> semicolons, eg.
>
> INTEGER, DIMENSION(2, 2, 2) :: B = [1, 2; 3, 4;; 5, 6; 7, 8]
>
> One issue with this syntax is of course that the values are given row major,
> which is different from the memory layout of Fortran an thus also the way
> RESHAPE works.
>
> Alternatively [1, 2; 3, 4] could represent
> / 1 3 \
> \ 2 4 /

Not so good.

[Ian Harvey]

On 2019-07-22 22:25, Evert Provoost wrote:
...

> 1) Add a 'version specifier' (and make 'IMPLICIT NONE' the default).
>
> The 'version specifier' would be a line at the start of a file eg.
>
> FORTRAN 2018
>
> PROGRAM hello
> [...]
>

The standard does not specify anything like the concept of a source
file, so having a line "at the start of a file" is perhaps a more
significant change than you might imagine. For example, I have one
processor that expects all its source to be provided to it in one big
stream via standard input - not a proper file in sight.

The language does have quite a strong model of separate compilation for
program units, bar explicit references between program units (USE xxx,
SUBMODULE(xxx), etc). A single statement that applied across multiple
arbitrary program units would be quite counter to that.

> This way a compiler doesn't have to guess whether a file is for instance in
> fixed or free format. This would also allow standards to include changes that
> would break very old code but not modern practice. Eg. `IMPLICIT NONE` becoming
> the default. A compiler could also give warnings about better ways to do things
> when using older style constructs, etc.

It is implementation specific (just like the concept of a source file!),
but several processor implementations allow you to embed directives in a
source file that turn on (or off) warnings and other compiler options
while that source file is compiled. What you want sort of already
exists, though in a compiler specific way (but what a particular
compiler "could give warnings about" is also compiler specific).

> 2) Adding matrix literals.
>
> This is mostly a quality of life thing, but something like
>
> INTEGER, DIMENSION(2, 2) :: A = [1, 2; 3, 4]
>
> representing the matrix
> / 1 2 \
> \ 3 4 /
>
> is, to me, a lot more readable than
>
> INTEGER, DIMENSION(2, 2) :: A = TRANSPOSE(RESHAPE([1, 2, 3, 4], [2, 2]))

It might be more readable, but the choice of character is unfortunate.
The semicolon is already used as the statement separator. I think it
would take some quite complicated rewriting of the basic rules around
source forms to even permit a semicolon to appear within a statement
(outside of a character context or comment). You'd have to special case
array constructors or similar, which would be quite irregular.

...

[Steve Lionel]

On 7/23/2019 2:20 AM, Evert Provoost wrote:
> As gah4 noted the main proposal was to add a version specifier statement.

Before you do this, you need some sort of source form specifier. The ad
hoc use of file types has led to mass confusion among users. (You can
read my rant about this at
https://software.intel.com/en-us/blogs/2013/01/11/doctor-fortran-in-source-form-just-wants-to-be-free
)

I will also note that users are rarely correct in their belief of which
revision of the language they are coding for, a version specifier would
be unusable until a revision was published (as the name usually changes
along the way), and such a specifier doesn't support incomplete
implementations of a new revision.

One of Fortran's major strengths is its support for old code. Yes,
sometimes that preserves behavior that would be better off removed, but
any change that deliberately breaks old and previously valid code is a
non-starter.

Sympathetic as I am to the goal of reducing the ills of implicit
declaration, I think this is best served by the tools present in the
language (especially with the addition of IMPLICIT NONE (EXTERNAL) in
F2018) and local coding standards. As noted, all (as far as I know)
compilers have options to force typing and I'd expect them to add an
option to force external declarations/explicit interfaces as well (some
already have this). The community can help by complaining when someone
publishes code that doesn't meet modern coding standards.

--
Steve Lionel
Retired Intel Fortran developer/support
Email: firstname at firstnamelastname dot com
Twitter: @DoctorFortran
LinkedIn: https://www.linkedin.com/in/stevelionel
Blog: http://intel.com/software/DrFortran

[FortranFan]

On Monday, July 22, 2019 at 9:46:06 PM UTC-4, steve kargl wrote:

> .. If anyone

> thinks that all free-form source code uses IMPLICIT NONE, you need
> to spend sometime triaging bugs for gfortran. Changing the default

> will simply break too much code. ..


gfortran bugzilla is absolutely the wrong reference for this. An untold number of folks consciously eschew the IMPLICIT NONE statement in their attempt to create a MINIMAL working example toward their bug reports. That means nothing in terms of their actual codes which almost definitively will include IMPLICIT NONE in all scopes.

Should there be a convenient place now for anyone to peruse codes, it is GitHUb. IMPLICIT NONE is about the first thing I check whenever a Fortran project catches my attention. I've looked at many and I'm yet to find a project without IMPLICIT NONE.

So, can any reader point out a Fortran project with some seriousness of purpose (i.e., not someone's toy code) with free-form source with code listing available online does employs implicit typing without any IMPLICIT statement and would thus "break" if IMPLICIT NONE were adopted as the default in free-form source? My contention is there simply aren't any such codes.

I maintain IMPLICIT NONE is a needless appendage in modern codes which are all in free-form source. Explicit typing is "terminus a quo" for all practitioners of modern Fortran.

For Fortran standard to make IMPLICIT NONE the default for free-form source is about the least consideration the committee can extend to all new coders in Fortran who all are otherwise forced to sacrifice their precious time attending to the sordid legacy of implicit typing from the FORTRAN era (which they could care less) and the continued implications such as with the dangers of forgetting the IMPLICIT NONE statement in a program scope, particularly in modern constructs such as an INTERFACE block. This is an incalculably heavy price to pay, for many are absolutely revulsed by the language at that very point of instruction that is invariably part of an introduction to the language.

[Richard Weed]

Fortran Fans experience with looking at code from projects that adopt modern Fortran coding practices align with my own. I think its time that the compiler developers start being more proactive about forcing people to at least think about refactoring. A first step would be to make current standard compliance the default (ie don't automatically support legacy features). If you want/need support for obsolete features the user should be forced to set a compiler flag to get them. I would also include non-standard extensions in this. The heart of the issue is what I see is a narrow-sighted mindset in both the standard committee and compiler developers that support for 50 year old code is sacrosanct. Yes its a major reason Fortran is sgtill around but for most of us that moved away from anything that looks like F77 20 plus years ago its a boat anchor thats dragging both the language and people like me and I presume Fortran Fan that could care less about legacy support down.

[steve kargl]

FortranFan wrote:

> On Monday, July 22, 2019 at 9:46:06 PM UTC-4, steve kargl wrote:
>
>> .. If anyone
>> thinks that all free-form source code uses IMPLICIT NONE, you need
>> to spend sometime triaging bugs for gfortran. Changing the default
>> will simply break too much code. ..
>
>
> gfortran bugzilla is absolutely the wrong reference for this. An untold number of folks
> consciously eschew the IMPLICIT NONE statement in their attempt to create a MINIMAL
> working example toward their bug reports. That means nothing in terms of their actual
> codes which almost definitively will include IMPLICIT NONE in all scopes.

Having triaged a thousand or so bugs in gfortran's bugzilla, I may have
a different view on what users submit to bugzilla.

> So, can any reader point out a Fortran project with some seriousness of purpose (i.e.,
> not someone's toy code) with free-form source with code listing available online does
> employs implicit typing without any IMPLICIT statement and would thus "break" if
> IMPLICIT NONE were adopted as the default in free-form source? My contention is
> there simply aren't any such codes.

Not all substantial code bases are available to the public. Some of those codes date back
to when free form code was added to the standard. Some of those codes required expensive
certification, and any changes would require expensive re-certification. Do you honestly
believe that a programmer that switch from fixed form to free form 29 years ago immediately
started to add IMPLICIT NONE to everything she wrote?

> I maintain IMPLICIT NONE is a needless appendage in modern codes which are all
> in free-form source. Explicit typing is "terminus a quo" for all practitioners of modern
> Fortran.
>
> For Fortran standard to make IMPLICIT NONE the default for free-form source is about
> the least consideration the committee can extend to all new coders in Fortran who all
> are otherwise forced to sacrifice their precious time attending to the sordid legacy of
> implicit typing from the FORTRAN era (which they could care less) and the continued
> implications such as with the dangers of forgetting the IMPLICIT NONE statement in a
> program scope, particularly in modern constructs such as an INTERFACE block. This
> is an incalculably heavy price to pay, for many are absolutely revulsed by the language
> at that very point of instruction that is invariably part of an introduction to the language.

You're subscribed to the J3 mailing list. You have access to the working document.
What is stopping you from engaging J3 with your changings to 18-007r1.pdf?

--
steve

[FJ]

I notice that IMPLICIT NONE was already a common extension in the
Fortran77 era (but IMPLICIT DOUBLE PERCISION(A-H,O-Z) was still more
common). So when I switched to free format, I added IMPLICIT NONE at each
top of new F90 modules.

Unfortunately, the rule suggested by FortranFan has not been accepted (it
was supported by Richard Main who failed to convince other members).

So it is now far too late I think, even if smart compilers could suggest
the programmers to add IMPLICIT ONE.

[Evert Provoost]

On tuesday 23 July 2019 13:43:21 UTC+2 Ian Harvey wrote:
> The standard does not specify anything like the concept of a source
> file, so having a line "at the start of a file" is perhaps a more
> significant change than you might imagine. For example, I have one
> processor that expects all its source to be provided to it in one big
> stream via standard input - not a proper file in sight.
>
> The language does have quite a strong model of separate compilation for
> program units, bar explicit references between program units (USE xxx,
> SUBMODULE(xxx), etc). A single statement that applied across multiple
> arbitrary program units would be quite counter to that.

I see. Consider proposal (1) dropped.

The only other option of dropping implicit types would be to deprecate it and
provide tooling that detects variables that aren't declared and automatically
inserts the correct declaration. But that is nowhere near ideal.

> It might be more readable, but the choice of character is unfortunate.
> The semicolon is already used as the statement separator. I think it
> would take some quite complicated rewriting of the basic rules around
> source forms to even permit a semicolon to appear within a statement
> (outside of a character context or comment). You'd have to special case
> array constructors or similar, which would be quite irregular.

That's a stupid mistake on my part. I'll have to see whether there are any other
characters left then, or at least one that can't possibly be interpreted wrong
within square brackets. My first instinct would be the colon (:) but that
character has already a meaning elsewhere.

[Ron Shepard]

On 7/23/19 9:42 AM, Richard Weed wrote:
> A first step would be to make current standard compliance the default (ie don't automatically support legacy features). If you want/need support for obsolete features the user should be forced to set a compiler flag to get them.

I have used several compilers in the past that allowed basically every
option that was on the command line to also be included in the source
code as a comment directive. This was nonportable, of course, because it
applied to only that one specific compiler, but the general principle
would apply also in a portable way if such directives were standardized.

Instead of individual options that cover specific semantics or syntax,
one could also consider groups of such options that are invoked with a
single keyword. This could be used to invoke, for example, f2003
specific features. If this list of features associated with a single
keyword could be defined by the programmer, then the conventions
associated with an entire programming project could be encapsulated into
a single include or module file and invoked with a single directive
statement.

There is still a question about what the scope of such directive should
be: statement, program unit, or file. For example, if a directive says
to assume something specific about the following do loops, you might
need to enable and disable it several times within a program unit. These
situations complicate the language, and that is presumably why this
approach has not been taken up in the past by the standards committee.

$.02 -Ron Shepard

[FortranFan]

On Tuesday, July 23, 2019 at 10:49:33 AM UTC-4, steve kargl wrote:

> ..

> Having triaged a thousand or so bugs in gfortran's bugzilla, I may have
> a different view on what users submit to bugzilla.
>

Well, show a couple of links to existing bug incidents where you suspect the actual code would *break* if IMPLICIT NONE were to be made the default. Readers can then follow up with authors/administrators of those codes to determine the current status of those programs.

> .. Some of those codes required expensive

> certification, and any changes would require expensive re-certification.

This entire point is moot: these codes would need a re-certification if a compiler developer toward a required processor implementation as much as sneezes. Given the "expense" then, these codes are going to remain with FROZEN FORTRAN compiler(s) or whatever other godforsaken set of implementations the original certification came with i.e., until the powers-that-be move the entire system over to some other modern paradigm (usually modern C++), as it happens continually with financial institutions globally (for every one that remains with old FORTRAN/COBOL, there are countless others that have long divested of their legacy application frameworks altogether) or big agencies (e.g., CERN), at which point all that is left of FORTRAN of any relevance with those codes is a punch-card or two for a museum display or a demonstration in an YouTube video.

> Do you honestly believe that a programmer that switch from fixed form to free form 29 years ago immediately
> started to add IMPLICIT NONE to everything she wrote?
>

Absolutely. Especially if it wasn't a "cisgendered, heteronormative, patriarchal oppressor" (per present "woke" terminology, rather than the old trope of 'she') who had started writing the code in "free form 29 years ago".


> ..

> What is stopping you from engaging J3 with your changings to 18-007r1.pdf?

> ..

As explained previously, to have any success with the committee is like figuring out "the right way to order soup" as in this video: https://youtu.be/7WRxEY8o3kc.

Online discussions here and elsewhere are an absolute must to fine-tune the use cases and the points toward proposals, for the first reaction is inevitably the "no soup for you" guillotine to cut the neck off of each suggestion.

[ga...@u.washington.edu]

On Tuesday, July 23, 2019 at 4:43:21 AM UTC-7, Ian Harvey wrote:

(snip)

> The standard does not specify anything like the concept of a source
> file, so having a line "at the start of a file" is perhaps a more
> significant change than you might imagine. For example, I have one
> processor that expects all its source to be provided to it in one big
> stream via standard input - not a proper file in sight.

Stream data usually does have an EOF, so could satisfy the usual
requirements of file, but yes, Fortran doesn't have that.

I suspect it is C programmers that also use Fortran that understand this.

C does have the file concept, and specifically some statements can
be outside of any function, and so apply to all functions in the file.
I still think it is one of the stranger parts of C.

> The language does have quite a strong model of separate compilation for
> program units, bar explicit references between program units (USE xxx,
> SUBMODULE(xxx), etc). A single statement that applied across multiple
> arbitrary program units would be quite counter to that.

I remember figuring this out in Fortran 66 days. I had a program
that at the end of each subroutine had a comment like:

C ***************. END SUBROUTINE xxxx ***********************

right after the END statement.

Compile a subroutine as one file, and you get messages like

WARNING: NO EXECUTABLE STATEMENTS
WARNING: NO END STATEMENT

and then from the linker

WARNING: TWO MAIN PROGRAMS

anything after the END statement is a new program unit.
No executable statements, no END statement, and since no
FUNCTION, SUBROUTINE, or BLOCK DATA statement, it is obviously
a main program.

The fix was to move the comment above the END statement.

The DEFAULT statement I previously indicated would be for each
program unit, and go exactly where IMPLICIT goes now.

[steve kargl]

FortranFan wrote:

> On Tuesday, July 23, 2019 at 10:49:33 AM UTC-4, steve kargl wrote:
>
>> ..
>> Having triaged a thousand or so bugs in gfortran's bugzilla, I may have
>> a different view on what users submit to bugzilla.
>>
>
> Well, show a couple of links to existing bug incidents where you suspect
> the actual code would *break* if IMPLICIT NONE were to be made the default.
> Readers can then follow up with authors/administrators of those codes to
> determine the current status of those programs.

I have no interest in wasting my time to find old bug reports. I can assure
you that gfortran bugzilla reports included gzipped tar files, zip files, and
even URL's to projects where the reporter either found a legitimate bug or
did not understand the build process.

>> .. Some of those codes required expensive
>> certification, and any changes would require expensive re-certification.
>
> This entire point is moot: these codes would need a re-certification if a compiler
> developer toward a required processor implementation as much as sneezes. Given
> the "expense" then, these codes are going to remain with FROZEN FORTRAN

> commpiler(s) or whatever other godforsaken set of implementations the original

> certification came with i.e., until the powers-that-be move the entire system over
> to some other modern paradigm (usually modern C++), as it happens continually
> with financial institutions globally (for every one that remains with old FORTRAN/COBOL,
> there are countless others that have long divested of their legacy application frameworks
> altogether) or big agencies (e.g., CERN), at which point all that is left of FORTRAN of
> any relevance with those codes is a punch-card or two for a museum display or a
> demonstration in an YouTube video.

You have no idea what you're talking about do you? Just ranting. gfortran includes
Cray pointer support because it was too expensive to fix DOE codes. DOE paid an
intern to implement Cray pointer support in gfortran. gfortran has a bunch of -fdec
options now because it was too expensive to fix codes. Yes, these people asked for
changes to gfortran that would allow their code to compile without change. If the
resulting executable passed their internal testing, they were good to go. In fact,
there are a few changes waiting for review and committing where a company is
being paid to add additional nonstandard DEC (mis)features to gfortran, beacuse
some other company either cannot or does not have the ability to fix their Fortran
code.

>> Do you honestly believe that a programmer that switch from fixed form to free
>> form 29 years ago immediately
>> started to add IMPLICIT NONE to everything she wrote?
>>
>
> Absolutely. Especially if it wasn't a "cisgendered, heteronormative, patriarchal
> oppressor" (per present "woke" terminology, rather than the old trope of 'she')
> who had started writing the code in "free form 29 years ago".

Once again ranting without acknowledging the truth in what was written. The
decision to allow implicit typing in Fortran 90 occurred over 29 years ago.
Reflexively, using IMPLICIT NONE probably fell well down the list of things that
programmers started using 29 years.

>> ..
>> What is stopping you from engaging J3 with your changings to 18-007r1.pdf?
>> ..
>
> As explained previously, to have any success with the committee is like figuring
> out "the right way to order soup" as in this video: https://youtu.be/7WRxEY8o3kc.
>
> Online discussions here and elsewhere are an absolute must to fine-tune the
> use cases and the points toward proposals, for the first reaction is inevitably
> the "no soup for you" guillotine to cut the neck off of each suggestion.

From your posting the only use case I can infer is "I am tired of typing IMPLICIT
NONE. It should be the default."

Good luck with engaging J3.

--
steve

[FortranFan]

On Tuesday, July 23, 2019 at 1:29:19 PM UTC-4, steve kargl wrote:

> .. gfortran includes

> Cray pointer support because it was too expensive to fix DOE codes. DOE paid an

> intern to implement Cray pointer support in gfortran. ..
>

None of this has anything to do with the topic at hand: as to US DOE, I've worked with them also. The fact is one will be hard-pressed to find any US DOE Fortran code that employs implicit typing. Various groups at US DOE have long been advocates for explicit typing, just one illustration of that is this document which includes statements such as "After making all declarations explicit, implicit data declarations should be banned, by inserting "IMPLICIT NONE' in all program units." and who has tools and work processes to achieve the same:
https://w3.pppl.gov/~pshare/help/port_strategy.htm

Were the Fortran standard to finally adopt "IMPLICIT NONE" as default, US DOE will likely be the last department that has any issue with it. The few FORTRAN codes they employ will be unaffected by the change while the rest, like EnergyPlus simulator in the link below, having long been ported away from FORTRAN!
https://www.energy.gov/eere/buildings/articles/energyplus-overcomes-computer-language-barrier

"For the first 17 years of its existence, EnergyPlus was written in the FORTRAN programming language. Now, DOE is releasing EnergyPlus 8.2.0, the first version written in C++. More modern than FORTRAN, C++ has better built-in features for software development, testing, and maintenance. It also has a larger ecosystem of software libraries and development tools, better access to new high-performance hardware, and a significantly larger developer community. DOE believes that the language change will help spur the evolution of EnergyPlus and its integration into additional applications and services."


> ..

> From your posting the only use case I can infer is "I am tired of typing IMPLICIT

> NONE. It should be the default." ..

Just that the 'I' here refers not to me but to Evert Provoost who initiated this thread with the perfectly valid point, "make 'IMPLICIT NONE' the default", and also to countless others like OP who, as lay practitioners of Fortran, are being disregarded and mistreated by the Fortran standard committee for a bull-headed notion which is entirely *fake news* that a change to a default IMPLICIT NONE will "break" old code.

[FortranFan]

On Tuesday, July 23, 2019 at 9:04:32 AM UTC-4, Steve Lionel wrote:

> One of Fortran's major strengths is its support for old code. Yes,
> sometimes that preserves behavior that would be better off removed, but
> any change that deliberately breaks old and previously valid code is a
> non-starter.

Except that the language now has 8 features (and counting) that are DELETED, meaning "previously valid code" with those features can now legitimately be rejected by a conforming processor.

Several of the features - such as arithmetic IF, nonblock DO construct, H edit descriptor, and assigned GO TO - are indeed being employed today in a couple of commercial process simulation software which has considerable user base in chemicals and related industry. These software vendors would otherwise be mindful of these deletions in Fortran but for the fact they hold no interest in Fortran any longer and are actively ridding themselves of their legacy code bases altogether.

Given such background, there is no justifiable basis any longer not to delete IMPLICIT TYPING from the language, especially considering the harm due to status quo and the benefits of the change to a default of IMPLICIT NONE.


> .. the tools present in the

> language (especially with the addition of IMPLICIT NONE (EXTERNAL) in

> F2018) ..

Short of a default IMPLICIT NONE, coders would have rather preferred a new "EXPLICIT ALL" statement in Fortran 2018! It beats having to type in "IMPLICIT NONE (TYPE, EXTERNAL)"!!!!

The entire situation with continued support of implicit typing in Fortran starting with the Fortran 90 revision is a textbook illustration of "failure of imagination".

[Steve Lionel]

On 7/23/2019 4:14 PM, FortranFan wrote:
> On Tuesday, July 23, 2019 at 9:04:32 AM UTC-4, Steve Lionel wrote:
>
>> One of Fortran's major strengths is its support for old code. Yes,
>> sometimes that preserves behavior that would be better off removed, but
>> any change that deliberately breaks old and previously valid code is a
>> non-starter.
> Except that the language now has 8 features (and counting) that are DELETED, meaning "previously valid code" with those features can now legitimately be rejected by a conforming processor.

I have never been in favor of deleting features, and every compiler
implementor I have asked has said their compilers would never remove
features. The only requirement of the standard here is that compilers be
able to diagnose deleted features when asked (and one typically needs to
specify which revision you're checking against).

Deleting features from the standard just creates problems for
implementors when the standard no longer specifies how they interact
with other features. I don't have a problem with marking features as
obsolescent.

The committee has regularly objected to proposals that break existing,
standard-conforming code, no matter how noble the cause. I fully support
that position.

[steve kargl]

FortranFan wrote:

> On Tuesday, July 23, 2019 at 1:29:19 PM UTC-4, steve kargl wrote:
>
>> .. gfortran includes
>> Cray pointer support because it was too expensive to fix DOE codes. DOE paid an
>> intern to implement Cray pointer support in gfortran. ..
>>
>
> None of this has anything to do with the topic at hand: as to US DOE, I've worked with them also. The fact is one will be hard-pressed to find any US DOE Fortran code that employs implicit typing. Various groups at US DOE have long been advocates for explicit typing, just one illustration of that is this document which includes statements such as "After making all declarations explicit, implicit data declarations should be banned, by inserting "IMPLICIT NONE' in all program units." and who has tools and work processes to achieve the same:
> https://w3.pppl.gov/~pshare/help/port_strategy.htm

Once again you're missing the point. Cray pointers were added to gfortran
because DOE did not or could not fix their code to not use Cray pointers. It was
the path of least resistance to pay an intern a few months salary to implement
Cray pointers. The -freal-* family of options is another example of changes to
gfortran motivated by a national lab (DOE or NASA can't remember which),
because it would be too costily to copy the code and manually port it to use a
higher precision. The point here, that you seem to be conveniently missing,
is that there are likely free form codes that do not use IMPLICIT NONE, which
will break if it is made the default. J3 simply will not pursue this type of
change.

--
steve

[steve kargl]

FortranFan wrote:

> On Tuesday, July 23, 2019 at 9:04:32 AM UTC-4, Steve Lionel wrote:
>
>> One of Fortran's major strengths is its support for old code. Yes,
>> sometimes that preserves behavior that would be better off removed, but
>> any change that deliberately breaks old and previously valid code is a
>> non-starter.
>
> Except that the language now has 8 features (and counting) that are DELETED,
> meaning "previously valid code" with those features can now legitimately be
> rejected by a conforming processor.
>

As you seem to be fond of posting URL's.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16222

"Deleted Feature" does not mean much when it comes to writing a compiler.

Shortly after this was fixed by me, the author of G95 was compelled to offer
the same deleted feature, because users started to ask for it.

--
steve

[FortranFan]

On Tuesday, July 23, 2019 at 5:19:36 PM UTC-4, steve kargl wrote:

> ..

> As you seem to be fond of posting URL's.
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16222
>
> "Deleted Feature" does not mean much when it comes to writing a compiler.

> ..

The aspect of deleted features in the standard, such as (1) Real and double precision DO variables, means a lot, in fact they are priceless in their value to achieve better programs - portable and conforming to an ISO standard - on account of diagnostics a processor must issue, as shown below:

--- begin console output ---
C:\temp>type p.f90
program cc
real x, dx
dx = 0.1e0
do x = 0.e0, 1.e0, dx
print*, x
end do
end

C:\temp>gfortran -c -std=f2018 -Wall p.f90
p.f90:4:6:

do x = 0.e0, 1.e0, dx
1
Error: Deleted feature: Loop variable at (1) must be integer

C:\temp>
--- end output ---

That some processors continue to support deleted features as a non-standard extension is irrelevant to all those who follow the standard.

It's time implicit typing is added to the list of deleted features in the standard.

[steve kargl]

FortranFan wrote:

> On Tuesday, July 23, 2019 at 5:19:36 PM UTC-4, steve kargl wrote:
>
>> ..
>> As you seem to be fond of posting URL's.
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16222
>>
>> "Deleted Feature" does not mean much when it comes to writing a compiler.
>> ..
>
> The aspect of deleted features in the standard, such as (1) Real and double precision DO variables,
> means a lot, in fact they are priceless in their value to achieve better programs - portable and
> conforming to an ISO standard - on account of diagnostics a processor must issue, as shown below:

(program removed)

> That some processors continue to support deleted features as a non-standard extension
> is irrelevant to all those who follow the standard.

> It's time implicit typing is added to the list of deleted features in the standard.

Apparently, you failed to read the URL. I'm the one that added that deleted feature
to gfortran for backwards compatibility with g77 and user request. I know how
gfortran works, so your cute little program is not too informative.

It is not irrelevant for those that want to just get a program to run without
chasing the whims of J3. For example, when you convince J3 that implicit
typing is a deleted feature or that IMPLICIT NONE is the default, I'll likely have
to create an option for that as well.

But, you have already informed us that you have no interest in engaging
J3 about IMPLICIT NONE as the default, so I suspect you won't approach J3
about deleting implicit typing from the standard. I guess the point is
moot.

While you rally your minions to do your J3 engagement, can you also take on
deleting fixed-form source code. This would remove a whole bunch of headaches
with writing a Fortran compiler (except every Fortran compiler known to man
supports all deleted features).

--
steve

[ga...@u.washington.edu]

On Tuesday, July 23, 2019 at 1:14:13 PM UTC-7, FortranFan wrote:
> On Tuesday, July 23, 2019 at 9:04:32 AM UTC-4, Steve Lionel wrote:

> > One of Fortran's major strengths is its support for old code. Yes,
> > sometimes that preserves behavior that would be better off removed, but
> > any change that deliberately breaks old and previously valid code is a
> > non-starter.

> Except that the language now has 8 features (and counting) that
> are DELETED, meaning "previously valid code" with those features
> can now legitimately be rejected by a conforming processor.

> Several of the features - such as arithmetic IF, nonblock DO
> construct, H edit descriptor, and assigned GO TO - are indeed being
> employed today in a couple of commercial process simulation
> software which has considerable user base in chemicals and related
> industry.

For the features you list, it would be fairly easy to write a program
which would convert such programs to using non-deleted features.
(I don't know that it has been done, though.)

On the other hand, REAL DO variables aren't quite as easy.

I haven't done it so recently, but some years ago I would convert
BASIC programs to Fortran, from a version of BASIC that only has
floating point variables. Yes BASIC programmers have to be careful
in their use. If is convenient to have them for that use, though.

[ga...@u.washington.edu]

On Tuesday, July 23, 2019 at 4:43:21 AM UTC-7, Ian Harvey wrote:

(snip, someone wrote)

> > INTEGER, DIMENSION(2, 2) :: A = [1, 2; 3, 4]

> > representing the matrix
> > / 1 2 \
> > \ 3 4 /

> > is, to me, a lot more readable than

> > INTEGER, DIMENSION(2, 2) :: A = TRANSPOSE(RESHAPE([1, 2, 3, 4], [2, 2]))

> It might be more readable, but the choice of character is unfortunate.
> The semicolon is already used as the statement separator. I think it
> would take some quite complicated rewriting of the basic rules around
> source forms to even permit a semicolon to appear within a statement
> (outside of a character context or comment). You'd have to special case
> array constructors or similar, which would be quite irregular.

One that always seemed strange to me in C, is the semicolons
used in the for statement. Since they are also statement separators,
it seems wrong to me, but I get used to it.

I suspect that for the same reason, that they are inside brackets,
that the compiler could figure them out. It does complicate error
detection and message generation, though.

[FortranFan]

On Tuesday, July 23, 2019 at 4:36:38 PM UTC-4, Steve Lionel wrote:

> ..

> Deleting features from the standard just creates problems for
> implementors when the standard no longer specifies how they interact
> with other features. I don't have a problem with marking features as
> obsolescent.
>
> The committee has regularly objected to proposals that break existing,
> standard-conforming code, no matter how noble the cause. I fully support
> that position.

> ..

My points are a) deleting features from the standard is actually a good thing, it informs practitioners the time for those features is in the past and b) there is clear precedent for such an action in the standard and which is the guiding light on the path forward.

Time is up for implicit typing in Fortran.

For the preponderance of evidence is no actual code will "break" if IMPLICIT NONE is made the default, only because all codes either employ 'implicit none' as-is or in certain rare instances involving legacy applications, the programs adopt "IMPLICIT INTEGER(I-N), xxx(A-H,O-Z)" where xxx is REAL/DOUBLE PRECISION.

Thus the change to a default IMPLICIT NONE incurs only a certain limited cost that is easily surpassed by the immense benefit to posterity.

[Richard Weed]

Wow, go away from this thread for a few hours and a food fight breaks out :>). I have some comments related to the IMPLICIT NONE "discussion" but I'll start by addressing one idea related to the matrix initialization issue brought up by the OP. While it would be hard to implement array constructors along the line of what the OP wanted, there is a modification to the standard that suggests itself that would be beneficial. Namely, remove the requirement to use RESHAPE when the compiler knows what the shape of the target array is. ie. just

Integer(INT32), DIMENSION(3,3) :: anArray = &
[ 1, 2, 3, &
4, 5, 6, &
7, 8, 9]

keeping in mind Fortran's default column major storage. Its still up to the programmer to get the columns and rows in the desired order

O.K. now onto the IMPLICIT NONE discussion. As I mentioned earlier, I think a way to "have our cake and eat it too" is for the compiler vendors/developers require folks who need to use any feature that has been officially removed from the language or declared obsolecent by the standard to manually enable them with a compiler flag (say --enable-obsolete-features) that would override the default IMPLICIT NONE that would otherwise occur. Support for these features would still be in the compilers. The big difference is that those of us who choose not to use them don't have to go through extra effort to use a feature thats become a standard part of how we program.

One thing thats puzzled me over the years is whay the standard committee appears to be hell bent on forcing Fortran programmers to write way more code to accomplish the same task than other languages require you to do. To me an example of this is their adamant refusal (see the various working papers etc on www.j3-fortran-org in particular Van Snyders 19-175.txt where he says that the committe made an xplicit decision not to produce any particular
containers, such as lists, stacks, queues, trees.... Rather, support
should be provided to develop containers.) to even consider something like a standard STL like facility for Fortran which based on my own experience trying to develop codes in the real world (and not the "cloud-cuckoo land" the committee appears to live in) would be a lot more beneficial in the short term than a full blown templating capability. So interpolating the words from Synders paper, the committee is basically saying " we won't lift a finger to actually make the users life easier, instead we will make it harder by throwing him a bone with "containers" which will probably be another bloat-filled addition to the langauge that the developers will find almost impossible to implement and tell them if you want a generic list go write it yourself"


Also, like Fortran Fan I've worked with DOE labs in the past and know of no current widely used Fortran code coming out of any lab that uses Cray pointers.
Unfortunately, there is also a pesistent believe among a few developers I know that "Fortran 90 is slower that Fortran 77" and one group I've worked with in the past still clings to fixed source code to the point that they refactored some free-field code I gave them BACK to fixed format.

Finally, for Steve Kargl. You keep talking about how "expensive" it would be refactor some codes. Yes if you aren't willing to acquire or develop decent tools and associated programming skills that can at least do the basic tasks required to convert from fixed to free format (and those have been around in one form or the other for a very long time). If you have appropriate tools and skills however it can be relatively trivial even for very large code bases. I wrote my own little code to do fixed to free conversion about 20 years ago and have applied it to a lot of codes. One in particular has over 300,000 lines of Fortran 77 code. I converted the entire code base in less that 2 days and would have done it sooner if I didn't periodically run into what I like to call Stupid Programmer Tricks that I had to go back and modify my code to handle. (my favorite one was some guy who thought it was cool to put a space between every letter in SUBROUTINE and FUNCTION). So the "expense" you keep harping on sounds to me like a "dog ate my homework" excuse to do nothing.

O.K. now back to the food fight :>)

[steve kargl]

Richard Weed wrote:

> Finally, for Steve Kargl. You keep talking about how "expensive" it would be refactor
> some codes. Yes if you aren't willing to acquire or develop decent tools and associated
> programming skills that can at least do the basic tasks required to convert from fixed
> to free format (and those have been around in one form or the other for a very long time).
> If you have appropriate tools and skills however it can be relatively trivial even for very
> large code bases. I wrote my own little code to do fixed to free conversion about 20 years
> ago and have applied it to a lot of codes. One in particular has over 300,000 lines of Fortran
> 77 code. I converted the entire code base in less that 2 days and would have done it sooner
> if I didn't periodically run into what I like to call Stupid Programmer Tricks that I had to go
> back and modify my code to handle. (my favorite one was some guy who thought it was
> cool to put a space between every letter in SUBROUTINE and FUNCTION). So the "expense"
> you keep harping on sounds to me like a "dog ate my homework" excuse to do nothing.

This has nothing to do with refractoring code with automated tools.
That would be cheap. The expense comes when the modified code needs
to re-certified (e.g., code review from a 3rd party, big dollar contractor
with appropriate credentials to even look at the code (i.e., a DOE, NASA,
and/or DoD security clearance)).

I have been told by a NASA employee and an individual associated with the NRC that
a change to a code that has gone through a ceritification process would require
modified code to be re-certified. Something about human life and errors. I don't
know what that process is/was. But given NASA's reputation for rules, it would be expensive.
Expensive as in $$$$ not time [1].

I can also assure you that the individual who wrote the Cray pointer support
worked for LLNL. You can check the fortran@ mailing list archive from
2005 for the details.

I can also assure that at least one branch of DoD will not accept changes to certified codes
without a re-certification process. Again, an expensive process.

[1] https://history.nasa.agov/sts1/pages/computer.html

--
steve

[Clive Page]

On 23/07/2019 02:36, Lynn McGuire wrote:

> Clive Page with Cobalt Blue used to sell a two products called FOR_STUDY and FOR_STRUCT that would structure Fortran 77 code.  I own a copy but I have never used it.

Unless there are two of us, you are confusing me with someone else.


--
Clive Page

[FortranFan]

On Tuesday, July 23, 2019 at 10:41:29 PM UTC-4, Richard Weed wrote:

> .. now onto the IMPLICIT NONE discussion. ..
> Also, like Fortran Fan I've worked with DOE labs in the past ..
> Finally, for Steve Kargl. You keep talking about how "expensive" it would be refactor some codes. ..


To reiterate, no one will be able to point to any *actual* Fortran code toward any currently used applications that will be adversely impacted by a change in the standard to a default 'implicit none'.

One can be essentially 100% certain all the Fortran codes out there, especially those in free-form source, have 'implicit none' in all their scopes.

One can be quite sure all the fixed-form source out there also employ 'IMPLICIT NONE' or they have other explicitly introduced IMPLICIT statements (IMPLICIT INTEGER(I-N), xxx(A-H,O-Z)'.

As pointed by @fj, 'IMPLICIT NONE' was a widely favored extension to ANSI FORTRAN 1978 (aka FORTRAN 77) in compilers well before the Fortran 90 revision; this was likely one of the most supported enhancements to Fortran 90. Microsoft FORTRAN compilers toward FORTRAN 77 even included support for 'IMPLICIT NONE' as an extension. I just happened to get a call the other day to answer some technical questions around process calculations on a code base that was first written toward MS DOS using Microsoft FORTRAN. So I just went back and reviewed this enterprise's revision control system for source code dating back to late 1980s and sure enough, it had IMPLICIT NONE in all the files even when there were other aspects that were, programmatically considering, not the 'best' practices.

So the issue of refactoring existing code does not even arise here, for they will all continue to work on account of already having explicit IMPLICIT instructions in their program scopes.

Thus, any and all supporters of a default IMPLICIT NONE, such as OP, can state there remains no LEGITIMATE basis with the concern a change in the standard with *break* existing code.

US Department of Energy (DOE), for example, will not point out - one can contend - a single application based on FORTRAN/Fortran, among the few that still remain in these 2 languages, which employ implicit typing. Thus DOE too will not be concerned with this change; if anything, there will be some sub-departments at DOE that will welcome the change to the Fortran standard.

The burden to disprove such an assertion must now lie entirely on the naysayers, it's up to them to point out some actual applications that can *break* with the proposed change.

Those who have in their nature to place bets can safely wager no such applications are going to surface, that the arguments will remain on the MYTHICAL notion some existing code will *break* and everyone else should get dragged down in the process, a notion that is sadly the stuff of cults, not a progressive approach to a practical language for scientific and technical computing.

[Richard Weed]

I've been an Aerospace Engineer for more than 40 plus years. I was one of the guys in the early years of the Shuttle program that did verification and validation on Shuttle guidance and control software (ie things that peoples lives depend on so I know a little about that). The only software I know that needs certification/recertification is the actual flight software that runs inside a vehicles computers. I doubt that in this day and age it is written in Fortran. Shuttle actually had a purpose built language called Higher Algorithm language (if I remember correctly - Yes HAL) that was used to build the actual binaries that ran in the Shuttle flight control computers. We used Fortran to verify that the algorithms, math etc that made up the final control laws were valid and also for mission simulation tools. Robust software for flight control systems are one the reasons (maybe the main one) for Ada. Having said that, I'm more than willing to admit I'm wrong if you can name one Fortran program (and I mean the actual program and the group inside NASA or DoD that uses it) that requires as you put it "expensive recertification"

[Steve Lionel]

On 7/23/2019 10:41 PM, Richard Weed wrote:
> One thing thats puzzled me over the years is whay the standard committee appears to be hell bent on forcing Fortran programmers to write way more code to accomplish the same task than other languages require you to do. To me an example of this is their adamant refusal (see the various working papers etc onwww.j3-fortran-org in particular Van Snyders 19-175.txt where he says that the committe made an xplicit decision not to produce any particular

> containers, such as lists, stacks, queues, trees.... Rather, support
> should be provided to develop containers.) to even consider something like a standard STL like facility for Fortran which based on my own experience trying to develop codes in the real world (and not the "cloud-cuckoo land" the committee appears to live in) would be a lot more beneficial in the short term than a full blown templating capability. So interpolating the words from Synders paper, the committee is basically saying " we won't lift a finger to actually make the users life easier, instead we will make it harder by throwing him a bone with "containers" which will probably be another bloat-filled addition to the langauge that the developers will find almost impossible to implement and tell them if you want a generic list go write it yourself"

This is a misrepresentation of the committee discussion. Pretty much all
of us agreed that something like an STL would be a good thing. But
before you run, you have to learn to walk, and that means developing the
underpinnings in the language that would allow for something like an STL
and to get some experience with them.

[Dick Hendrickson]

Oddly, that's also why Cray supported "Cray pointers." ;)

Dick Hendrickson

[Lynn McGuire]

Sorry about that, I had a brain freeze !

The Cobalt Blue guy's name is actually Clyde Lightfoot.

Lynn

[dpb]

For nuclear side, there's 10CFR50 that requires QA program by federal
law that covers the entire enchilada of design and build. Codes used
for safety-related calculations fall under that broad brush as well as a
valve.

It took quite some effort to produce enough verification data to get
FSAR (Final Safety Analysis Report) approved including final licensing
hearings before full ACRS (Advisory Committee on Reactor Safeguards)
that had at least three sessions on pieces of core design I was involved
in. I couldn't begin guess how many hearings there were overall
covering everything from A to Z in that process and the countless man
and computer hours that went into supporting it.

Now, there's not much activity but when we proposed replacing a minor
analog level control system consisting of one input with a redundant
sensor with absolutely identically-functioning microprocessor-based
system they went totally nonlinear in the amount of effort it took to
qualify. And that was something that could write the entire control
logic in about 10 lines; RELAP5 contained several 100K LOC and had
almost innumerable input options of various modeling scenarios alone.

The nuclear codes were every bit as complex but it was somewhat easier
to get experimental data against which to do comparisons than it is to
actually melt a core for confirmation test data (altho there were actual
experiments at INEL towards that goal for the purpose of providing
vendors such data against which to qualify models).

We did almost a month of physics testing at Oconee I before actual power
ascent at enormous cost to the utility of lost power revenue because as
the first of the generation of plants NRC required a final verification
of model's ability to predict all sorts of conditions before final
blessing for power operation.

That's all 40 year in my rear view mirror now, but stuff like that does
exist and one didn't find the Fortran codes in the open literature
because every vendor had their own proprietary version with their own
features and protected those zealously...

--

[Evert Provoost]

I'm also not too keen on breaking changes. That's why 'IMPLICIT NONE as default' was coupled to the 'version specifier' idea (which appears to be infeasible as, among other reasons, Fortran doesn't have a concept of a source file).

However, I do not think that 'having to recertify code' is a realistic consequence of this particular change. I'm no expert at high integrety software but I would assume that not only the code itself would need to be verified but the result after compilation too as a compiler could contain a bug which would render the result unreliable. Ie. changing compiler would already require a recertification.

When it would be feasible to update your compiler, 'IMPLICIT NONE' could become a default without too much hassle. As Richard Weed proposed, those who do not want to change their code could use a compiler flag (which most will probably provide). All remaning code could, to my understanding, fairly easily be 'autofixed'.

[Robert Orban]

In article <96461bdc-651c-4665...@googlegroups.com>,
evert.p...@gmail.com says...
>Dear reader,

>
>2) Adding matrix literals.
>
>This is mostly a quality of life thing, but something like

>
>INTEGER, DIMENSION(2, 2) :: A = [1, 2; 3, 4]
>
>representing the matrix
>/ 1 2 \
>\ 3 4 /
>
>is, to me, a lot more readable than
>
>INTEGER, DIMENSION(2, 2) :: A = TRANSPOSE(RESHAPE([1, 2, 3, 4], [2, 2]))
>

Within the limits of the current standard, you could do this to improve
readability:

INTEGER, DIMENSION(2, 2) :: A = &
TRANSPOSE(RESHAPE( [ &
1, 2, &
3, 4 ], &
[2, 2]))

[ga...@u.washington.edu]

On Wednesday, July 24, 2019 at 2:30:13 PM UTC-7, Evert Provoost wrote:
> I'm also not too keen on breaking changes.
> That's why 'IMPLICIT NONE as default' was coupled to the
> 'version specifier' idea (which appears to be infeasible as,
> among other reasons, Fortran doesn't have a concept of a source file).

It just means that you would need the version specifier for
each program unit. That is, the place where you now put the
IMPLICIT NONE. I suppose there is a small advantage of the
version specifier over IMPLICIT NONE, especially as it makes it
obvious which version is needed. Once added, it is forward, but
not backward compatible. (Fortran 90 compilers won't recognize
VERSION 1990 statements.)

Without a change, compilers could warn about lack of IMPLICIT
NONE, or warn for actual implicit declared variables. In the
olden days, compilers printed maps of variable name, type, and
address. One could look through this, and notice unexpected
variables (especially due to spelling errors). It might be
that compilers can still make such maps, but not by default.

[dpb]

For nuclear side, there's 10CFR50 that requires a rigorous QA program

that covers the entire enchilada of design and build. Codes used for
safety-related calculations fall under that broad brush as well as a valve.

It took quite some effort to produce enough verification data to get the

FSAR (Final Safety Analysis Report) approved including final licensing
hearings before full ACRS (Advisory Committee on Reactor Safeguards)
that had at least three sessions on pieces of core design I was involved
in. I couldn't begin guess how many hearings there were overall
covering everything from A to Z in that process and the countless man

and computer hours that went into supporting it. And the hearings were
just the window dressing on top of the thousands of pages of
documentation for filings and subsequent responding to what seemed
interminable questions and requests for further data.

Not all of if had to do directly with verification of the underlying
codes, but had to get through that initial qualification step before
they would accept results of core calculations, even down to proving the
reduction from ENDF raw nuclear cross data to the multi-group constants
used and the code which did those calculations (a totally proprietary
mostly FORTRAN code that ran on the Philco 2000 initially before the
transition to the CDC when it was rewritten again in FORTRAN. Those
codes never were released as being considered highly proprietary and a
commercial competitive advantage).

--

[Gary Scott]

:) proprietary is often of great commercial importance. We were once
forced to release simulation code to a competitor by a customer. There
were so many language extensions in use peculiar to a particular
computer system we used that it turned out to be virtually useless to
the competitor who used Vaxen :) Ultimately, it took 4 vaxen to
accomplish what we did with one mini and several parallel processing IO
processors.

[Richard Weed]

> This is a misrepresentation of the committee discussion. Pretty much all
> of us agreed that something like an STL would be a good thing. But
> before you run, you have to learn to walk, and that means developing the
> underpinnings in the language that would allow for something like an STL
> and to get some experience with them.

Steve,

I just cut and pasted what was in Snyders paper. If its a "mispresentation" then you should talk to him. I went to the J3 site looking for a copy of the standard interpretation document and started reading some of the papers listed there. If there was "discussion" about an STL its not reflected in any of those documents (that I can see). If the committee is indeed open to an STL like facility then thats great news. Unfortunately, I'm afraid that by the end of your current "five year plan" that will take 15 years for the compiler developers to implement and another 10 to fix all the bugs and regressions we will still be left with something thats a bloated mess that most programmers (if there are any Fortran programmers left by then) will consider too much of a hassle to waste their time on. If I was in your position the first thing I would do is mandate the committee go study a variety of C++ and Python codes (and there are dozens out there) in areas like CFD, Finite Elements, Climate-Weather-Ocean (CWO) modeling etc. to get a real world view of just how templates in general and the STL containers etc are actually used in the real world before going down a path that just adds more bloat to the language. In the areas of I work in (CFD and FEM), what I see is a mix of good and bad programming (usually written by grad students), a lot of STL, moderate use of user defined templates, and the rest mostly CTRAN (C written like Fortran). Developing an something like an STL should be the first priority.

[Ron Shepard]

On 7/25/19 8:14 AM, dpb wrote:
> For nuclear side, there's 10CFR50 that requires a rigorous QA program
> that covers the entire enchilada of design and build.  Codes used for
> safety-related calculations fall under that broad brush as well as a valve.

I knew some people who worked with nuclear reactor codes in the 1980s,
and their verification process involved comparing the output results
down to the last bit. That meant that the production codes had to run
(or be simulated for) EBCDIC characters and IBM floating point format,
with the same rounding, truncation, hexadecimal format, and everything.
It also meant that an improved numerical method could not be
incorporated into the code, as the improved accuracy would be flagged
during the verification process as an error.

This was during the time when improved numerical algorithms, IEEE
floating point, ASCII characters, and relatively cheap workstation
hardware were all becoming available. That verification process seemed
self-defeating.

$.02 -Ron Shepard

[dpb]

The vendor for whom I worked had at least some more common sense than
that...we did nuclear comparisons to roughly the equivalent of known
precision in the data...fortunately, NRC accepted it as we no doubt
would have never qualified anything otherwise.

In a later life as consultant, was asked to help another office on a
code verification project for a nuclear cask vendor and they had made
that mistake. Two weeks was all I could stomach so I bailed on that
one... :)

--

[Steve Lionel]

On 7/25/2019 9:54 AM, Richard Weed wrote:
>> This is a misrepresentation of the committee discussion. Pretty much all
>> of us agreed that something like an STL would be a good thing. But
>> before you run, you have to learn to walk, and that means developing the
>> underpinnings in the language that would allow for something like an STL
>> and to get some experience with them.
> Steve,
>
> I just cut and pasted what was in Snyders paper. If its a "mispresentation" then you should talk to him. I went to the J3 site looking for a copy of the standard interpretation document and started reading some of the papers listed there. If there was "discussion" about an STL its not reflected in any of those documents (that I can see). If the committee is indeed open to an STL like facility then thats great news. Unfortunately, I'm afraid that by the end of your current "five year plan" that will take 15 years for the compiler developers to implement and another 10 to fix all the bugs and regressions we will still be left with something thats a bloated mess that most programmers (if there are any Fortran programmers left by then) will consider too much of a hassle to waste their time on.

Thanks - I'm very familiar with Van's papers and his interpretations of
events. (Van and I often sit next to each other at J3 meetings, and we
talk a lot.) You're right that discussions at J3 meetings aren't
recorded. I try to capture in my own notes interesting issues, and I've
encouraged the committee secretary to include more in the minutes than
just which papers passed, but it's hard to write down everything,
especially when these discussions don't all occur in the same room.

I'm well aware of the extended timeline for implementation of past
revisions, which is why I have a goal of a smaller and faster release.
Not continually one-plussing the work list is a big part of this, as is
trying to minimize major features. I am heartened that large parts of
Fortran 2018 are already finding their way into available compilers.

I'll repeat that we spent months surveying the user community to find
out what they wanted. We spent more months sorting through the 100+
responses looking for common themes and getting ideas, then figuring out
which of these were feasible. We were left with a very long list, not
all of which is going to make it in this time. But it was all valuable.

> If I was in your position the first thing I would do is mandate the
committee go study a variety of C++ and Python codes (and there are
dozens out there) in areas like CFD, Finite Elements,
Climate-Weather-Ocean (CWO) modeling etc. to get a real world view of
just how templates in general and the STL containers etc are actually
used in the real world before going down a path that just adds more
bloat to the language. In the areas of I work in (CFD and FEM), what I
see is a mix of good and bad programming (usually written by grad
students), a lot of STL, moderate use of user defined templates, and the
rest mostly CTRAN (C written like Fortran). Developing an something like
an STL should be the first priority.

First of all, I can't "mandate" anything; I don't have that sort of
authority over WG5, but I can and do nudge it along a path that I
believe will be productive, with buy-in from the other members. I like
to think that my decades on the implementation side help with this.
Second, we have a number of users on the committee, with experience in
the sorts of codes you mention, who have been guiding our work here. But
we can't have an STL without underpinnings in the language to make such
a thing possible. It would be folly to try to design a STL before we
know how it would work with the language.

As an exercise, take some small part of the C++ STL you think is useful
and write an outline of it in Fortran, along with an example of it being
used. (No need for it to actually build and run.) What does it look
like? How does it make application development easier? What language
concepts do you need to invent for it to work? What problems did you
have to solve along the way?

Are you willing to help us? Write some papers, come up with a proposal
for language design, come to our meetings!

[dpb]

@Steve L +123.314

If I were 20 year younger still, maybe... :)

--

[Steve Lionel]

On 7/25/2019 4:46 PM, dpb wrote:
>> Are you willing to help us? Write some papers, come up with a proposal
>> for language design, come to our meetings!
>>
> @Steve L +123.314
>
> If I were 20 year younger still, maybe... :)

And how young do you think *I* am?

[dpb]

On 7/25/2019 6:39 PM, Steve Lionel wrote:
> On 7/25/2019 4:46 PM, dpb wrote:
>>> Are you willing to help us? Write some papers, come up with a
>>> proposal for language design, come to our meetings!
>>>
>> @Steve L +123.314
>>
>> If I were 20 year younger still, maybe... :)
>
> And how young do you think *I* am?

I know you're at least N younger than I... :)

--

[dpb]

On 7/25/2019 10:08 AM, Ron Shepard wrote:

...

I've never worked in the areas, but there are a number of posters on The
Mathworks site in biomed and medical arenas that are quite upset at the
rate of change in MATLAB and often do not update owing to similar concerns.

What their actual formal requirements are haven't really been the topic
so not aware, but I'd presume something similar as 10CFR50 is in place
in aviation, medical fields, etc., etc., etc., ... where there is
significant government oversight and/or regulation on safety and/or
health related subjects.

--

[Dominik Gronkiewicz]

> The committee has regularly objected to proposals that break existing,
> standard-conforming code, no matter how noble the cause. I fully support
> that position.

So why does the committee even exist if they don't do their job of fixing the language? Just announce "this language is dead and in maintenance-only phase, the party is closed, move over to other languages for new projects".

The compatibility argument is bullshit (as usual), because it's a matter of changing the default behavior, not redefining the whole language. Just introduce compiler switch like -fno-implicit-none, as has been done for other cases. Or just add "implicit default" instruction. If someone is lazy enough they can't add one line to their code so it keeps working, i don't see why everyone else should suffer. The defaults should always enforce *recommended* practices, those who don't follow it should go through the inconvenience of using compatibility options, not the other way around.

[Thomas Koenig]

Dominik Gronkiewicz <gro...@gmail.com> schrieb:

> So why does the committee even exist if they don't do their job
> of fixing the language?

The part of after the "if" is false, therefore the part before
that is meaningless.

> The compatibility argument is bullshit (as usual),

You have no idea of the kind of bug reports / requests we get.

[Beliavsky]

I would prefer that the standard mandate that every main program and module and every procedure not in a module have the IMPLICIT NONE statement. If you find a code that compiles with implicit typing, it arguably has two problems -- the implicit typing and the lack of IMPLICIT NONE.

I understand the argument for backwards compatibility and don't think keeping implicit typing as the default is a big problem. Decent programmers will use IMPLICIT NONE in their codes.

[Milan Curcic]

I'm fine with typing implicit none for the next 50 years, and perhaps longer.

I prefer compiler developers focusing on more productive tasks.

[FortranFan]

On Monday, July 29, 2019 at 5:49:41 PM UTC-4, Milan Curcic wrote:

> I'm fine with typing implicit none for the next 50 years, and perhaps longer.

> ..

@Milan Curcic,

You may be "fine with typing implicit none for the next 50 years, and perhaps longer" but why should every potential new practitioner of Fortran be subject to the same? I too don't mind it, however many a bright, young mind with whom I'm fortunate to work with in industry - particularly chemical engineers who were among the audience during your seminar with AIChE the other day - have expressed strong reservations to me about it; it just doesn't seem fair to ignore their feedback.

Say a future Fortran standard revision makes 'IMPLICIT NONE' the default as proposed by OP, it will still retain the support toward IMPLICIT statements, no change to that support is implied (!). So all the existing code with IMPLICIT NONE or other IMPLICIT statements will function the same as they do with the current standard and so will all the new code that includes "IMPLICIT NONE".

The only change really will be the person employing a processor implementation that is conformant with that new standard (and who might also be a new user of Fortran) will effectively get to view Fortran as being a language with support toward 'explicit typing' by default. "They" will not be forced to worry about "stating the obvious" via a superfluous 'IMPLICIT NONE' instruction in all their program scopes, particularly the INTERFACE block where it's oft-forgotten.

However those used to the legacy of Fortran 2018 and earlier revisions, such as you, can continue to type "IMPLICIT NONE" and they will incur no harm other than perhaps an epiphany at a later stage in life for their frequent exercises in futility.

From the tone and text of your interactions with customers in the comment section of your book (of which I have purchased a copy) at MEAP, you appear particularly conscious to "inclusive" language and manners which is all the "rage" now with the "woke" crowd everywhere.

So then, what aspect of the proposed change by OP here, which is truly 'inclusive' in that it supports both the views, yours to be able to keep typing "IMPLICIT NONE" and of those who wish to progress ahead, do you wish to DENY?

> I prefer compiler developers focusing on more productive tasks.

And what productive tasks by compiler developers will be thwarted by the change to a default of "IMPLICIT NONE"? Almost every processor implementation has a compile-time option to enforce it. The work will be primarily to repurpose an existing capability, not that I'm unmindful of the effort involved. It's just that the change proposed by OP is about as close to a very low-cost, extremely high benefit suggestion as there ever will be one, particularly in terms of existing compilers.

About the only counterargument from a language perspective is that about "breaking existing code" to which I would be fully sympathetic if I knew it wasn't "fake news"; in this day and age, the concern is entirely hypothetical.

The resistance to a change of default "IMPLICIT NONE" is untenable, particularly when a certain compromise can be pursued, say with free-form source only which already has certain semantic and syntax differences compared to fixed-form where the fragile code likely to "break" will exist, if at all.

[ga...@u.washington.edu]

On Monday, July 29, 2019 at 9:14:45 PM UTC-7, FortranFan wrote:
> On Monday, July 29, 2019 at 5:49:41 PM UTC-4, Milan Curcic wrote:

> > I'm fine with typing implicit none for the next 50 years,
> > and perhaps longer.

> You may be "fine with typing implicit none for the next 50 years,
> and perhaps longer" but why should every potential new practitioner
> of Fortran be subject to the same?

I get tired of typing FUNCTION at the top of functions, SUBROUTINE
at the top of subroutines, and CALL for calling subroutines.

Maybe we should change the standard to avoid the work of typing
in all those.

[FortranFan]

On Tuesday, July 30, 2019 at 12:32:16 AM UTC-4, ga...@u.washington.edu wrote:

> ..

> I get tired of typing FUNCTION at the top of functions, SUBROUTINE
> at the top of subroutines, and CALL for calling subroutines.
>
> Maybe we should change the standard to avoid the work of typing
> in all those.

False equivalence.

[steve kargl]

FortranFan wrote:

> On Monday, July 29, 2019 at 5:49:41 PM UTC-4, Milan Curcic wrote:
>
>> I'm fine with typing implicit none for the next 50 years, and perhaps longer.
>> ..
>
> @Milan Curcic,
>
> You may be "fine with typing implicit none for the next 50 years, and perhaps longer" but why should every potential new practitioner of Fortran be subject to the same?

Backwards compatibility? Valid code today should be valid code tomorrow.
And, yes, I'm aware of the list of deleted features as I'm the person that
implemented REAL do-loop indices in gfortran. Guess what, people wanted
a means to continue to use their formerly conforming code without
changing it.

Again, you're subscribed to the J3 mailing list. Put together a paper and
submit it for consideration.

Your suggestion of making IMPLICIT NONE the default is simply silly.
It won't happen. It won't happen just like your proposal that a vendor
or gfortran developers could provide an experimental implementation
for exceptions.

--
steve

[spectrum]

Seriously, I've been using a lot of shorthand notations for all of these (including
IMPLICIT NONE, all of variable attributes, etc) defined in a cpp util file,
so as to write and read them more easily. Because it is just cpp,
the code can be converted to the standard form anytime.

# And I know that such macros can make a code obscure for other people
(particularly in a group environment), so just using for my own coding.

As for IMPLICIT NONE, I initially mapped it to "explicit" (for a bit of brevity XD),
but later changed it to "___" because I don't want to "read"
it again and again. I avoid using a compiler option for it to minimize
the number of options (and minimize source-dependent switching for options).

Some editors (incl. Emacs) sometimes support auto-completion keywords for
_writing_ a code. But in my case, I would like to avoid _reading_ long keywords
(because I feel it is very tiring to read long ones repeatedly).

But this is just my impression and experience (no request for the standard)...

---
Apart from that, I'm interested why Beliavsky thinks IMPLICIT NONE should be the default,
for a bit more details (I 100% agree with this, although I guess it won't happen for
backward compatibility). Possibly, some unfortunate cases/bugs happened by inadvertently
forgetting to type it somewhere? (e.g. when using Fortran from R?)

[spectrum]

Also, as suggested in the very first post, if the standard considers introducing
a statement specifying the use of new syntax or rules at the top of a module,
I think the problem of backward compatibility does not happen
(because old codes just don't have such a statement).

With a similar approach, I wanted to have the capability of specifying
the KIND of default numerical literals (both for integers and reals), because
attaching _rk and _ik etc for all literals make the code less readable again.
(But this is not a strong request, again, because compiler options could handle
them somehow.)

[robin....@gmail.com]

YHTOBJ.
Perhaps you should be happy with just reading 4-letter words (joke).

Do you use variable names of more than one letter?
Did you know that it's possible to use names with more than 1 letter
and digit?

[Evert Provoost]

To put the poposals into context:

Me and a few others are working on a little talk on "How to tackle a programming
assignment" for the first-year informatics, mathematics and physics students at
our university. This includes a small example assignment in Python (the only
languages used by all three courses in their first year). The assignment is to
ask the user for two times in a (H)H:(M)M format (eg. 0:4 or 12:30) and then
compute the difference between the two (where the second time is assumed to be
after the first). The program should also notify the user of invalid input and
it should keep asking for input until the user provides a valid time.

After the talk there is some time left and I wanted to have some other versions
ready. Mainly to show that the problem breakdown is the same for all languages.
As the talk is also given to physics students I chose Fortran as one of those
other languages.

The code doesn't fully comply with the assignment, input has to be 5 characters
wide in the Fortran version and excess characters are ignored (if you know a
simple solution for the latter, please let me know). However I prefer to 'hide
the ugly parts' as Fortran is a great language for number crunching. String
handling is a known weakness and I did not want to highlight that in my example
implementation.

The code I came up with:


program clock

implicit none
integer :: h1, m1, h2, m2

call get_time(1, h1, m1)
call get_time(2, h2, m2)

print '("Difference in minutes: ", I0)', &
modulo(60*h2 + m2 - 60*h1 - m1, 24*60)

end program clock

subroutine get_time(n, h, m)

use, intrinsic :: iso_fortran_env

implicit none
integer, intent(in) :: n
integer, intent(out) :: h, m
character :: sep
integer :: error

do
write (*, '("Time ", I0, ": ")', advance='no') n
read (*, '(I2, A1, I2)', iostat=error) h, sep, m

if (error == IOSTAT_END) then
stop
else if (error == 0) then
if (sep == ':' .and. &
h >= 0 .and. h < 24 .and. &
m >= 0 .and. m < 60) then
return
end if
end if

print '("Invalid input. Please try again.")'
end do

end subroutine get_time


Proposals 1 and 3 stem from writing this example.

I'm not going to add much to the "implicit none as default" discussion, I'm new
to the language and am thus unable to weigh the pro's and con's of such a
change. However, I do think that it could make the language, as silly as it
sounds, feel 'fresher' which is somewhat important to newcomers.

Writing 'Fortran 2018' or something similar (with a reserved keyword for in
development versions) in every compilation unit would be a bit better but not
substantially, although it could allow for other backwards incompatible changes
without breaking old code.


Proposal 3 would enable a simple, fully valid implementation of the assignment.
A potential further addition could be a MATCH='REQUIRED' option to READ.
Together with the edit descriptor syntax in proposal 3,

READ (*, '(I(1,2), ":", I(1,2))', IOSTAT=error, MATCH='REQUIRED') h, m

would be enough to fully implement the assignment.

Making READ allocate allocatable character arrays would of course also make
fully compliant code somewhat easier to write.


Proposal 2 is really just a small quality of life thing to make matrix heavy
code a bit nicer to read and write, but the proposed syntax is indeed not great.


Sincerely,
Evert Provoost

[robin....@gmail.com]

On Tuesday, July 30, 2019 at 5:23:54 PM UTC+10, spectrum wrote:
> Also, as suggested in the very first post, if the standard considers introducing
> a statement specifying the use of new syntax or rules at the top of a module,
> I think the problem of backward compatibility does not happen
> (because old codes just don't have such a statement).
>
> With a similar approach, I wanted to have the capability of specifying
> the KIND of default numerical literals (both for integers and reals), because
> attaching _rk and _ik etc for all literals make the code less readable again.

You don't need them for all literals.
You don't need then for default integers.
You can also specify E and D.

[spectrum]

On Tuesday, July 30, 2019 at 5:12:35 PM UTC+9, robin...@gmail.com wrote:
>
> YHTOBJ.
> Perhaps you should be happy with just reading 4-letter words (joke).
>
> Do you use variable names of more than one letter?
> Did you know that it's possible to use names with more than 1 letter
> and digit?

Yes, I use longer (but not too long) names for variables (which are meaningful),
while decreasing the length of Fortran keywords (which looks like too lengthy to me).

Interestingly, Rust uses "fn" for "function" as a keyword, though I think
it is a bit an extreme case (as compared to other languages).
https://doc.rust-lang.org/std/keyword.fn.html

Indeed, if each keyword (particularly for variable attributes) is long,
a statement for declaring variables with multiple attributes becomes longer and longer.
I guess this "verbosity" problem may become more apparent when generics will come
in Fortran202x.

[spectrum]

On Tuesday, July 30, 2019 at 5:16:58 PM UTC+9, robin...@gmail.com wrote:

> You don't need them for all literals.
> You don't need then for default integers.
> You can also specify E and D.

As for integer, 64-bit integers have been becoming more common than before
(because of an increase in data size and the possible number of iterations etc).
If I want to use 64-bit integers consistently, I also need to attach _ik (etc) in
many places, in addition to _rk. I could simply suppress warnings about
"type conversion", but it could also be risky if external routines are involved.

Then, attaching _ik etc to an existing code makes math expressions even less
unreadable (to me). I.e., though "Fortran" mean formula translation (right),
the formulas (in a code) are becoming more and more oriented to machines
rather than for human math... (just IMHO).

[spectrum]

On Tuesday, July 30, 2019 at 5:31:20 PM UTC+9, spectrum wrote:

Hmm, sorry, "even less" is a typo of "even more"... XD

# Again, I emphasize that my comments above are my impression and preference,
not a request thing. I know that preference varies extremely among people
(e.g. between me and Robin).

[Gary Scott]

Well, that's a little extreme. Having to type implicit none however is
just embarrassing. It was never a good idea/design and never will be.
I vote for changing the default and using compiler switch for the
outdated behavior.

[Milan Curcic]

On Tuesday, July 30, 2019 at 12:14:45 AM UTC-4, FortranFan wrote:
> You may be "fine with typing implicit none for the next 50 years, and perhaps longer" but why should every potential new practitioner of Fortran be subject to the same?

I don't argue for it, nor think it's a good idea.

If we were starting from scratch, the correct choice is obvious. I think we're all on the same page here.

The fact is, it's what we got. In my opinion, changing the default behavior in the language standard would create more problems than it would solve. So far, the only benefit I see is: less typing.

You say that for *you* the benefits far outweigh the cost, and I believe you, but for *me* it's the opposite. I am personally invested in Fortran's backward compatibility in both my research and business, and this guides my position on this matter.

Cheers,
milan

[FortranFan]

On Tuesday, July 30, 2019 at 10:09:03 AM UTC-4, Milan Curcic wrote:

> .. I am personally invested in Fortran's backward compatibility in both my research and business, and this guides my position on this matter.
> ..

@Milan Curcic,

Thank you for your feedback.

When you state, you are "personally invested in Fortran's backward compatibility in both my research and business," can you please clarify whether you are referring to the specific item here with a default "IMPLICIT NONE", or you refer to "backward compatibility" in a general sense.

Also, is there a program/application you can point to in your "research and business" that relies on the current standard formulation toward implicit typing and thus might "break" due to the proposed change to a default "IMPLICIT NONE"?

[Milan Curcic]

On Tuesday, July 30, 2019 at 10:31:15 AM UTC-4, FortranFan wrote:

> When you state, you are "personally invested in Fortran's backward compatibility in both my research and business," can you please clarify whether you are referring to the specific item here with a default "IMPLICIT NONE", or you refer to "backward compatibility" in a general sense.

I refer to backward compatibility in general. I think it's one of key strengths of Fortran as a language.

> Also, is there a program/application you can point to in your "research and business" that relies on the current standard formulation toward implicit typing and thus might "break" due to the proposed change to a default "IMPLICIT NONE"?

Sure, you can look at either WRF (weather prediction, runs operationally at 100s of orgs around the world) or HYCOM (ocean prediction, runs operationally at dozens of orgs around the world, including US Navy). Both have code that uses implicit typing, even some free-form code. Mostly in the underbelly of the software stack. If you dig deep enough, you'll find it.

And this is just in my field of expertise, for two software stacks (out of dozens). I am confident this is not an isolated instance, you just need to know where to look.

Cheers,
milan

[FortranFan]

On Tuesday, July 30, 2019 at 11:09:48 AM UTC-4, Milan Curcic wrote:

> ..

> Sure, you can look at either WRF (weather prediction, runs operationally at 100s of orgs around the world) or HYCOM (ocean prediction, runs operationally at dozens of orgs around the world, including US Navy). Both have code that uses implicit typing, even some free-form code. Mostly in the underbelly of the software stack. If you dig deep enough, you'll find it.
>
> And this is just in my field of expertise, for two software stacks (out of dozens). I am confident this is not an isolated instance, you just need to know where to look.

> ..


I've been keeping an eye on WRF for some time and some basic high-level familiarity with it, especially since I went over the book by Chirila et al. on Fortran for Earth Sciences: https://www.springer.com/gp/book/9783642370083

So consider WRF and the following link with the section on "coding standards":
http://www2.mmm.ucar.edu/wrf/users/contrib_info.php

which states clearly, "Use IMPLICIT NONE and declare all variables"

But now it is entirely possible there are certain layers in WRF the above consideration is violated.

However, such a situation in some WRF layer is by no means a supporting argument to retain backward compatibility in the Fortran standard i.e., until and unless someone can veritably prove the situation in WRF with the offending code utilizing implicit typing is indeed per design and that such codes are to be truly maintained as such, that they are really unmodifiable, and that too over the next decade.

Indications are WRF source code is mostly meant to be open source, portable, and conformant to a set of NOT-STUPID coding standards with "Use IMPLICIT NONE and declare all variables" being part of the most important items. But with such a large codebase, it is always possible to have a few things that "fall through the cracks". Such a situation is usually not a desired state, rather a DEFECTIVE one toward which powers-that-be, should there ones with WRF, are often willing to shell out top-dollar to rectify. And a defective state is not of any relevance to the advancement of Fortran.

Under the circumstances, the proposed change by OP to a "default IMPLICIT NONE" in Fortran standard is far more likely to be welcomed as a progressive change rather than being resisted by those at WRT due to any concerns with backward incompatibility.

[Phillip Helbig (undress to reply)]

In article <732797da-7003-4d05...@googlegroups.com>,
Milan Curcic <cao...@gmail.com> writes:

> Sure, you can look at either WRF (weather prediction, runs operationally at=
> 100s of orgs around the world) or HYCOM (ocean prediction, runs operationa=
> lly at dozens of orgs around the world, including US Navy). Both have code =
> that uses implicit typing, even some free-form code. Mostly in the underbel=

> ly of the software stack. If you dig deep enough, you'll find it.
>

> And this is just in my field of expertise, for two software stacks (out of =
> dozens). I am confident this is not an isolated instance, you just need to =
> know where to look.

I think that I understand both sides of the issue, but I have a
question: How difficult is it to find all the variables then explicitly
declare them? I'm sure that there are tools which would produce a list,
and from the initial letter the declaration is obvious. So if IMPLICIT
NONE were made the default, then, yes, such old codes wouldn't compile
out of the box, but we're talking a few minutes to insert the
declarations. This could probably even be done automatically.

[ga...@u.washington.edu]

On Tuesday, July 30, 2019 at 1:14:14 AM UTC-7, Evert Provoost wrote:


(snip)

> This includes a small example assignment in Python (the only
> languages used by all three courses in their first year). The assignment is to
> ask the user for two times in a (H)H:(M)M format (eg. 0:4 or 12:30) and then
> compute the difference between the two (where the second time is assumed to be
> after the first). The program should also notify the user of invalid input and
> it should keep asking for input until the user provides a valid time.

(snip)

> write (*, '("Time ", I0, ": ")', advance='no') n
> read (*, '(I2, A1, I2)', iostat=error) h, sep, m

Fortran input formatting was designed in the days of punched cards,
where data can in specific card columns.

List directed input was added in the days of online terminals, where
getting the columns right is harder.

In C you could:

scanf("%d:%d", &h, &m)

but most likely you wouldn't do that. If there is no :,
this scanf will stop at that point, leaving what is next
waiting to be read later. This is confusing to users.

The usual C solution is to read in the line, and then

h=m=0;
sscanf(line, "%d:%d", &h, &m);

(Note that if a number is given without a colon, it
goes into h, and m is zero. Maybe not what you want.)

I suspect that reading in the whole line, and then using internal
READ to extract the values is the best way in Fortran, too.

READ a line into a CHARACTER variable, use INDEX to find a ':',
use assignment to replace it with space or comma, and internal
list-directed READ to get the values.

It would be nice if the built-in I/O routines could satisfy
every strange formatting situation one might run into, but
they never will.

C's scanf stops each conversion when a character can't be
used, and leaves it for the next one. %d will stop at anything
that isn't a digit (or prefix sign) up to the length given.

Also, scanf is defined not to change variables that aren't
used, if no valid conversion is done for them. (Note the h=m=0.)

Fortran does not have this feature. If a READ doesn't succeed,
the standard leaves the input values undefined. (Unless changed
since I last checked.) This also complicates some situations.

[ga...@u.washington.edu]

On Tuesday, July 30, 2019 at 2:23:33 PM UTC-7, Phillip Helbig (undress to reply) wrote:

(snip)

> I think that I understand both sides of the issue, but I have a
> question: How difficult is it to find all the variables then explicitly
> declare them? I'm sure that there are tools which would produce a list,
> and from the initial letter the declaration is obvious. So if IMPLICIT
> NONE were made the default, then, yes, such old codes wouldn't compile
> out of the box, but we're talking a few minutes to insert the
> declarations. This could probably even be done automatically.

A quick google search shows that Bloomberg has 25 million lines
of Fortran. I suspect that there are others also with millions
of lines.

Yes it should be possible to automate many code changes.
With millions of lines, it will still take a long time.

It would be nice to have programs that would automatically
change from deleted or obsolescent features to the suggested
replacements. I haven't seen those.

Do compilers have an option to require IMPLICIT NONE?
That would seem easy to add, if desired.

[Lynn McGuire]

On 7/22/2019 7:55 AM, Evert Provoost wrote:
> Dear reader,
>
> As far as I can tell the 'call for proposals' for Fortran 202x is closed, but if
> small(-ish) ideas are still welcome:
>
> The following is the perspective of someone first learning Fortran. However, in
> my personal experience beginners tend to notice quirks and some possible
> improvements easier. This of course also means that some of these proposals
> might be naive or even borderline ignorance (in which case: please do call me
> out for it).
>
> Anyway, here are a couple of ideas for the next (or later) Fortran standard:
>
>
>
> 1) Add a 'version specifier' (and make 'IMPLICIT NONE' the default).
>
> The 'version specifier' would be a line at the start of a file eg.
>
> FORTRAN 2018
>
> PROGRAM hello
> [...]
>
> This way a compiler doesn't have to guess whether a file is for instance in
> fixed or free format. This would also allow standards to include changes that
> would break very old code but not modern practice. Eg. `IMPLICIT NONE` becoming
> the default. A compiler could also give warnings about better ways to do things
> when using older style constructs, etc.
>
>
>
> 2) Adding matrix literals.
>
> This is mostly a quality of life thing, but something like
>
> INTEGER, DIMENSION(2, 2) :: A = [1, 2; 3, 4]
>
> representing the matrix
> / 1 2 \
> \ 3 4 /
>
> is, to me, a lot more readable than
>
> INTEGER, DIMENSION(2, 2) :: A = TRANSPOSE(RESHAPE([1, 2, 3, 4], [2, 2]))
>
> This could even be extended to more complex arrays by, for instance, repeating
> semicolons, eg.
>
> INTEGER, DIMENSION(2, 2, 2) :: B = [1, 2; 3, 4;; 5, 6; 7, 8]
>
> One issue with this syntax is of course that the values are given row major,
> which is different from the memory layout of Fortran an thus also the way
> RESHAPE works.
>
> Alternatively [1, 2; 3, 4] could represent
> / 1 3 \
> \ 2 4 /
>
>
>
> 3) Extending the format syntax to also allow variable width numbers and string
> literals in READs.
>
> This would, as far as I can tell, make READ as, and even more, useful as C's
> scanf.
>
> One way of doing this is to add a range option to the width in an edit
> descriptor by adding a (lo,hi) syntax. For instance, a integer between 1 and 9
> digits wide could be specified as I(1,9). By leaving out the upper limit, thus
> writing: I(1,), any integer would be accepted.
>
> A string literal in the format of a READ would simply be interpreted as a
> separator which has to be present.
>
> A concrete example would be:
>
> READ (*, '(I4, "-", I(1,2), "-", I(1,2))') YEAR, MONTH, DAY
>
> Which would accept '2019-6-03' but not, for instance, '19-006-', '2019--08-06'
> or '2019-06*07'.
>
> Cases like '(I(1,), "00")' do pose an issue as to how these should be
> interpreted.
>
>
>
> Sincerely,
> Evert Provoost

4) Ability to declare variables in the code at the point of usage rather
than the beginning of the module. Unless, this has already been added
to a newer version of Fortran ?

Lynn

[ga...@u.washington.edu]

On Monday, July 29, 2019 at 9:40:33 PM UTC-7, FortranFan wrote:

(snip, I wrote)

> > I get tired of typing FUNCTION at the top of functions, SUBROUTINE
> > at the top of subroutines, and CALL for calling subroutines.

> > Maybe we should change the standard to avoid the work of typing
> > in all those.

> False equivalence.

I suppose so, but many languages manage to do without a special
keyword on function/subroutine definitions and calls.

Though partly they get away with that having reserved words,
such that function calls can't be confused with statements.

Does the OP really find it so hard to type IMPLICIT NONE?

I remember when first learning Fortran, wondering about such
long keywords as EQUIVALENCE.

[steve kargl]

Lynn McGuire wrote:

>
> 4) Ability to declare variables in the code at the point of usage rather
> than the beginning of the module. Unless, this has already been added
> to a newer version of Fortran ?
>

ROFL. You're about 10 years behind schedule.

F2008:
8.1.4 BLOCK construct

program foo
integer i
i = 42
block
integer i
i = 5
print *, i
end block
print *, i
end program foo

% gfcx -o z a.f90 && ./z
5
42

--
steve

[FortranFan]

On Tuesday, July 30, 2019 at 9:07:05 PM UTC-4, Lynn McGuire wrote:

> ..

> 4) Ability to declare variables in the code at the point of usage rather
> than the beginning of the module. Unless, this has already been added
> to a newer version of Fortran ?

> ..

It will be interesting to know whether @Lynn McGuire has completed the migration over to C++ of all the WATFOR-based FORTRAN code in the calculation engine of his commercial software toward chemical process simulation. Hopefully it has been a complete success in which case @Lynn McGuire might retain only an academic interest in Fortran.

[steve kargl]

Lynn's code depends on Watcom's compiler and its extensions.
Not sure where you came up with the WATFOR-base comment.

--
steve

[Phillip Helbig (undress to reply)]

In article <3575f5b5-3133-4dcd...@googlegroups.com>,

ga...@u.washington.edu writes:

> > I think that I understand both sides of the issue, but I have a
> > question: How difficult is it to find all the variables then explicitly
> > declare them? I'm sure that there are tools which would produce a list,
> > and from the initial letter the declaration is obvious. So if IMPLICIT
> > NONE were made the default, then, yes, such old codes wouldn't compile
> > out of the box, but we're talking a few minutes to insert the
> > declarations. This could probably even be done automatically.
>

> A quick google search shows that Bloomberg has 25 million lines
> of Fortran. I suspect that there are others also with millions
> of lines.
>
> Yes it should be possible to automate many code changes.
> With millions of lines, it will still take a long time.

It's probably worth the trouble, though.

> It would be nice to have programs that would automatically
> change from deleted or obsolescent features to the suggested
> replacements. I haven't seen those.

This is a much harder problem.

> Do compilers have an option to require IMPLICIT NONE?
> That would seem easy to add, if desired.

I'm sure that most do.

[Ron Shepard]

On 7/30/19 5:01 PM, ga...@u.washington.edu wrote:
> It would be nice to have programs that would automatically
> change from deleted or obsolescent features to the suggested
> replacements. I haven't seen those.

This might be a reasonable requirement for the standard itself. If a
revision deletes some feature, then maybe it should be accompanied by a
tool that automatically converts the source code to be conforming with
the new standard. Arithmetic if, real do loops, and so on could be like
this.

$.02 -Ron Shepard

[Ron Shepard]

On 7/30/19 8:07 PM, Lynn McGuire wrote:
> 4) Ability to declare variables in the code at the point of usage rather
> than the beginning of the module.  Unless, this has already been added
> to a newer version of Fortran ?

There are some people who want to initialize local variables in the
beginning where they are declared rather than where they are computed,
and there are others who want to move the declarations to where the
variables are computed rather than the beginning.

Just an observation.

$.02 -Ron Shepard

[Phillip Helbig (undress to reply)]

In article <_ka0F.109557$rc7....@fx07.iad>, Ron Shepard

<nos...@nowhere.org> writes:

> On 7/30/19 5:01 PM, ga...@u.washington.edu wrote:

> > It would be nice to have programs that would automatically
> > change from deleted or obsolescent features to the suggested
> > replacements. I haven't seen those.
>

> This might be a reasonable requirement for the standard itself. If a
> revision deletes some feature, then maybe it should be accompanied by a
> tool that automatically converts the source code to be conforming with
> the new standard. Arithmetic if, real do loops, and so on could be like
> this.

IIRC, the standard doesn't even require that a program be in a text
file; one could implement a compiler using people sitting at desks, as
Feynman did at Los Alamos.

[Evert Provoost]

On Tuesday 30 Juli 2019 23:33:57 UTC+2 ga...@u.washington.edu wrote:

Thanks for the detailed response, gah4.

> In C you could:
>
> scanf("%d:%d", &h, &m)
>
> but most likely you wouldn't do that. If there is no :,
> this scanf will stop at that point, leaving what is next
> waiting to be read later. This is confusing to users.
>
> The usual C solution is to read in the line, and then
>
> h=m=0;
> sscanf(line, "%d:%d", &h, &m);
>
> (Note that if a number is given without a colon, it
> goes into h, and m is zero. Maybe not what you want.)

And unfortunately that 'read in the line' is, without the getline from the
POSIX standard, a fairly non-trivial problem.

> I suspect that reading in the whole line, and then using internal
> READ to extract the values is the best way in Fortran, too.
>
> READ a line into a CHARACTER variable, use INDEX to find a ':',
> use assignment to replace it with space or comma, and internal
> list-directed READ to get the values.

That's why I noted that READ allocating an allocatable character array would
also ease these kinds of problems.

> It would be nice if the built-in I/O routines could satisfy
> every strange formatting situation one might run into, but
> they never will.

Well, proposal three introduces literals and a way to write a Kleene operator
"(0,)", all that's left is to add a choice operator and we've got the
expressiveness of regular expressions. ;-)

In all seriousness though, I think variable length values and custom separators
are common enough to warrant inclusion in READ.

> C's scanf stops each conversion when a character can't be
> used, and leaves it for the next one. %d will stop at anything
> that isn't a digit (or prefix sign) up to the length given.

That's why I later on in my response introduced "MATCH='REQUIRED'", that way
you have 'ignore everything else' (the default) 'stop reading on match'
("ADVANCE='NO'") and 'complain about things left unread' ("MATCH='REQUIRED'").

> Also, scanf is defined not to change variables that aren't
> used, if no valid conversion is done for them. (Note the h=m=0.)
>
> Fortran does not have this feature. If a READ doesn't succeed,
> the standard leaves the input values undefined. (Unless changed
> since I last checked.) This also complicates some situations.

I'm surprised C leaves those defined. In general I think it's good practice
to not rely on values that a function that failed could have changed. This makes
code harder to read. So I don't think Fortran's undefinedness is really an issue
here.

[Evert Provoost]

Op Wednesday 31 Juli 2019 08:52:49 UTC+2 Phillip Helbig (undress to reply) wrote:

> > > It would be nice to have programs that would automatically
> > > change from deleted or obsolescent features to the suggested
> > > replacements. I haven't seen those.
> >
> > This might be a reasonable requirement for the standard itself. If a
> > revision deletes some feature, then maybe it should be accompanied by a
> > tool that automatically converts the source code to be conforming with
> > the new standard. Arithmetic if, real do loops, and so on could be like
> > this.
>
> IIRC, the standard doesn't even require that a program be in a text
> file; one could implement a compiler using people sitting at desks, as
> Feynman did at Los Alamos.

That included tool could be a Fortran listing in the previous standard, so even
graduate students could 'execute' it. ;-)

[Ev. Drikos]

On 31/07/2019 12:33 AM, ga...@u.washington.edu wrote:
> On Tuesday, July 30, 2019 at 1:14:14 AM UTC-7, Evert Provoost wrote:
>
>
> (snip)
>

> The usual C solution is to read in the line, and then
>
> h=m=0;
> sscanf(line, "%d:%d", &h, &m);
>
> (Note that if a number is given without a colon, it

> ...

IMHO the solution seems more flexible, no matter what the programming
language is because programmers can code more fault tolerant programs.

An interactive program that hungs or exits with an error message when
the user forgets ie to enter the ':' isn't acceptable nowadays. Most
programs now read the user input and thereafter validate & convert it.

Ev. Drikos

[ga...@u.washington.edu]

On Tuesday, July 30, 2019 at 11:56:33 PM UTC-7, Evert Provoost wrote:

(snip, I wrote, regarding C's scanf)

> > Also, scanf is defined not to change variables that aren't
> > used, if no valid conversion is done for them. (Note the h=m=0.)

> > Fortran does not have this feature. If a READ doesn't succeed,
> > the standard leaves the input values undefined. (Unless changed
> > since I last checked.) This also complicates some situations.

> I'm surprised C leaves those defined. In general I think it's good practice
> to not rely on values that a function that failed could have changed.
> This makes code harder to read.
> So I don't think Fortran's undefinedness is really an issue here.

I ran into this one in Fortran many years ago. (VAX/VMS days.)

Trying to read in an array of unknown length with an implied-DO,
and END= to exit the loop. The standard leaves this undefined,
such that you can't use either the already input data or the loop
index variable.

I was close to submitting a bug report to DEC, but sometime later
found out about what the standard actually said. That was before
it was easy to find what the standard said, though.

The return value of scanf() is the number of items actually
read and converted, but many don't check that. There are no
conversion errors from scanf(). If a conversion can't be
done (alphabetic characters for %d, for example) the variable
isn't changed and the number of conversions done is returned.

But note also that there are no implied-DOs. Any loops
require an actual loop, and exit based on the returned
value.

[ga...@u.washington.edu]

On Tuesday, July 30, 2019 at 7:22:05 PM UTC-7, steve kargl wrote:
> Lynn McGuire wrote:

> > 4) Ability to declare variables in the code at the point of usage rather
> > than the beginning of the module. Unless, this has already been added
> > to a newer version of Fortran ?

> ROFL. You're about 10 years behind schedule.

> F2008:
> 8.1.4 BLOCK construct

It seems that there are two kinds of scoping, called lexical scope
and dynamic scope.

Some languages allow one to declare a variable anywhere, but the
variable is still allocated the same as if the declaration
appeared earlier. You won't have access to the variable outside
the scope.

BLOCK allows for actual allocation, including dynamically sized
arrays, which I believe is called dynamic scope.

As well as I know it, (and they might have changed), both C and
Java allow for lexical scope, where variables are declared later,
but still allocated on function/method entry. Newer versions of
C allow for variable length on auto arrays, and I don't know the
details for them. In Java, all arrays are explicitly allocated,
so this distinction doesn't occur.

Lynn didn't ask for dynamic scope, and maybe doesn't need it.

Most common in C and Java are for loops like:

for(int i=0; i<10; i++) ...

where the variable is lexically scoped to the loop. Java disallows
this if the variable is already declared outside the loop.
I am not sure how C treats it. One might not want the overhead
of allocation for this case.

[dpb]

On 7/31/2019 7:53 AM, ga...@u.washington.edu wrote:
> On Tuesday, July 30, 2019 at 11:56:33 PM UTC-7, Evert Provoost wrote:
>
> (snip, I wrote, regarding C's scanf)
>
>>> Also, scanf is defined not to change variables that aren't
>>> used, if no valid conversion is done for them. (Note the h=m=0.)
>
>>> Fortran does not have this feature. If a READ doesn't succeed,
>>> the standard leaves the input values undefined. (Unless changed
>>> since I last checked.) This also complicates some situations.
>
>> I'm surprised C leaves those defined. In general I think it's good practice
>> to not rely on values that a function that failed could have changed.
>> This makes code harder to read.
>> So I don't think Fortran's undefinedness is really an issue here.
>
> I ran into this one in Fortran many years ago. (VAX/VMS days.)
>
> Trying to read in an array of unknown length with an implied-DO,
> and END= to exit the loop. The standard leaves this undefined,
> such that you can't use either the already input data or the loop
> index variable.

...

Where the DEC/VAX Q descriptor was one of those invaluable
extension...that made using them almost inevitable.

--

[Lynn McGuire]

Sorry, I should have given an example.

program foo
integer i
double precision x
x = 0
do i = 1, 42
double precision y
y = x + 2
x = y
end do
print *, x
end program foo

Lynn

[Lynn McGuire]

Yes. In our C++ code, we do not declare and initialize variables until
they are used.

Lynn

[Lynn McGuire]

Actually, our F77 code compiles, links, and runs just fine on the Unix
boxen that I have tried it on. Sun and HP. Been a while though.

Our F77 code compiles and links on Intel IVF on Windows. It does not
run properly though as of several releases back.

Please note that I have FortranFan kill filed as he does not add
anything worthwhile to the conversations that I am interested in.

Lynn

[steve kargl]

It is, of course, a toy example, but you can place a BLOCK in
a do-loop.

program foo
integer i
double precision x
x = 0
do i = 1, 42

block

double precision y
y = x + 2
x = y

end block

end do
print *, x
end program foo

--
steve

[ga...@u.washington.edu]

On Wednesday, July 31, 2019 at 11:57:44 AM UTC-7, steve kargl wrote:
> Lynn McGuire wrote:

> > On 7/30/2019 9:22 PM, steve kargl wrote:
> >> Lynn McGuire wrote:

> >>> 4) Ability to declare variables in the code at the point of usage rather
> >>> than the beginning of the module. Unless, this has already been added
> >>> to a newer version of Fortran ?

(snip)

> It is, of course, a toy example, but you can place a BLOCK in
> a do-loop.

But do you want to do that? As I understand it, block variables
are allocated on block entry, and deallocated on block exit.
For variable sized arrays, they must be done after the size
is known. For scalars and constant sized arrays, they could be
allocated along with other program unit local variables.

While 42 isn't so many, it could be in a deeply nested loop,
and executed billions or trillions of times.

[Lynn McGuire]

EQUIVALENCES are so dangerous that the long word is useful.

Lynn

[steve kargl]

ga...@u.washington.edu wrote:

> On Wednesday, July 31, 2019 at 11:57:44 AM UTC-7, steve kargl wrote:
>> Lynn McGuire wrote:
>
>> > On 7/30/2019 9:22 PM, steve kargl wrote:
>> >> Lynn McGuire wrote:
>
>> >>> 4) Ability to declare variables in the code at the point of usage rather
>> >>> than the beginning of the module. Unless, this has already been added
>> >>> to a newer version of Fortran ?
>
> (snip)
>
>> It is, of course, a toy example, but you can place a BLOCK in
>> a do-loop.
>
> But do you want to do that? As I understand it, block variables
> are allocated on block entry, and deallocated on block exit.
> For variable sized arrays, they must be done after the size
> is known. For scalars and constant sized arrays, they could be
> allocated along with other program unit local variables.
>
> While 42 isn't so many, it could be in a deeply nested loop,
> and executed billions or trillions of times.
>

So (again a toy program), write it as

program foo
integer i
double precision x
x = 0

block
double precision y

do i = 1, 42

y = x + 2
x = y

end do
end block

print *, x
end program foo

y is a construct entity for the block. It is local to the construct.

You are more than welcomed to submit a paper to J3 to advocate
that the body of a do-loop or if-stmt should have its own scope,
which will then allow for declaration statements within the do-loop.

--
steve

[Ron Shepard]

On 7/31/19 1:57 PM, steve kargl wrote:

> It is, of course, a toy example, but you can place a BLOCK in
> a do-loop.
>
> program foo
> integer i
> double precision x
> x = 0
> do i = 1, 42
> block
> double precision y
> y = x + 2
> x = y
> end block
> end do
> print *, x
> end program foo

I have not used this feature of the language yet. How exactly is that
implemented? Is the automatic variable y allocated on the stack once, or
is it allocated every pass through the do-loop? If there are other "y"
variables in scope at that time, does that affect when and how often the
allocation occurs?

In a simple case like this, y is probably never really assigned to
memory at all, stack or otherwise, it probably just lives for a moment
in a register. Does having the block surrounding a small group of
statements help or hinder that kind of optimization?

$.02 -Ron Shepard