Fortran function remembers values (newbie help)

[epagone]

@jacobwilliams

Like I say, this would fix more bugs than it causes. I see it over and over again, year after year after year, people getting bitten by this dumb implicit save behavior. I have never seen anyone use it on purpose.

I concur, that’s my experience as well. In fact, I tried to put in on the map of true modern Fortran somehow.

However, let’s be honest: being things as they are, going through the standard route, implicit save will be “fixed” when some (many?) of us will be retired (if Fortran will be still a thing)… and I personally see it as the best case scenario. Life’s too short: I think we need to go through the compiler extension route and it is currently not available.

[certik]

I thought about how to fix this (and many other such issues) immediately, not in 10 or 20 years or after we retire.

I think the best way to do it is like TypeScript fixed JavaScript. My understanding of how they did it is by:

• First writing a compiler that understands all of current JavaScript
• Extending the compiler to support types and other nice features that they determined they want to have.
• Compiling all these extensions into standard JavaScript, so that existing JavaScript interpreters (i.e. browsers) can work with it
• Working with the wider JavaScript community to get some of the nicest features into JavaScript itself

I would like to use a similar approach with LFortran. Please help me brainstorm it how it can work.

• First write a regular compiler that supports all of current Fortran (we are well on the way)
• Extend the compiler (initially enabled with an optional flag) with whatever we want to get fixed. We can start with:
  • Reclaim the natural syntax integer :: x = 5 for initializing the integer, not the save
  • implicit none is removed and on all the time
• LFortran can either compile this as usual, or one can use LFortran to transpile into a subset of standard Fortran that works today with all Fortran compilers

Just like we decided to use a fancy preprocessor for stdlib, which makes stdlib completely not directly compilable with any Fortran compiler, but rather it depends on a single tool to transpile stdlib into standard Fortran. And we are fine with it (I certainly am!). We use the transpiled version in release tarballs, with fpm, etc. And yet we cannot contribute back directly to the transpiled version. One has to go into the git version which requires the fypp preprocessor.

So exactly in the same way, I can imagine having projects using these extensions and just use the LFortran tool to transpile into standard Fortran. Conceptually it is I think equivalent to stdlib + fypp. As well as to TypeScript + JavaScript.

[milancurcic]

@certik

First write a regular compiler that supports all of current Fortran (we are well on the way)

I think this is an essential step, so there are no surprises and so that people can run existing valid code without modifications.

@certik

• Reclaim the natural syntax integer :: x = 5 for initializing the integer, not the save
• implicit none is removed and on all the time

Since you intend to support both standard Fortran (great) and extensions (explicit and inferred typing), consider organizing and developing this as different type systems (as that’s what they are):

• Standard typing (current rules)
• Explicit typing (assume implicit none everywhere)
• Inferred typing (x = 42 is an integer, i = 1.234 is a real)

Standard typing should be the default if you intend to be friends with the existing Fortran ecosystem. And others, control with a flag, --typing=explicit, --typing=inferred, or similar.

[certik]

(I am actually not a fan of inferred typing except for interactive use. Either way we would have to play with it more. If there is a lot of interest in this, we can work on it.)

What I am thinking is to use this workflow to add and use new features such as:

• default arguments
• namespaces for modules
• generics!!
• error handling, perhaps using the try features as in Zig

I think any new proposal can be implemented in such a way to transpile into a form that current Fortran compilers can compile. That way we can actually start using it.

[Beliavsky]

@Beliavsky

Maybe Fortran could add an init attribute so that
integer, init :: i = 0, j = 1
means the same as

integer :: i,j
i = 0
j = 1

with the ability to change i and j later. So the user could only give a value to a variable within a declaration if the save, parameter, or init attribute appeared. Maybe init is not the right word, but the idea is that the user is required to say what he means.

I proposed the init attribute at GitHub and was informed that it was discussed two years ago, where it attracted some support. I think it’s a live issue.

[themos]

My thinking is that the place for executable statements is in the executable section and the place for initialization statements is in the initialization section.