It is both good rigor, and is one less thing to remember to put in the makefile. If, indeed, the compiler actually has a -fimplicit-none option.
1 Like
Hello everyone!
Thank you so much for your invaluable feedback on our proposal of the most common challenges and actions for the modernization of Fortran code. We’ve spent the last few days reviewing all of your comments to update our notes accordingly.
Building on all the collective wisdom accumulated so far, we’ve narrowed everything down to a list of “Top 10 Recommendations for Fortran Modernization”, as we were discussing at the start of this topic:
- Ensure strict compliance with modern Fortran standards.
- Declare procedures in modules for explicit interfaces, while leveraging submodules to decouple definitions and implementations.
- Restrict data scoping and visibility using modules in place of common blocks.
- Improve dummy argument semantics by preferring assumed shape arrays and specifying intents.
- Ensure data type consistency by using implicit none and preferring real(kind=kind_value) for declaring floating types.
- Avoid legacy and obsolete Fortran constructs, such as unstructured control mechanisms (GO TO, arithmetic IFs…), labeled do loops, etc.
- Enhance source code semantics using keywords such as pure, elemental, parameter…
- Adherence to code conventions within a codebase (e.g., variable naming, free form format).
- Adopt modern development practices for automated testing throughout the software development lifecycle, ease of managing software dependencies (e.g., FPM), packaging and distributing releases (CI/CD), and fostering collaboration and maintainability (e.g., git).
- Follow best practices on proper interoperability with C/C++.
What do you think of this updated proposal? Is there any other particularly relevant item that we should include? We welcome suggestions on any aspect!
Thank you in advice for your time!
2 Likes
Yes, and set kind_value in a module that is USEd throughout the program and check that the program still compiles when it is changed. This will expose the use of intrinsic functions that are specific to a certain precision and should be avoided. To illustrate, the code below compiles as is but does not compile with wp = kind(1.0), because the dsqrt and dble intrinsics are used.
module m
implicit none
integer, parameter :: wp = kind(1.0d0)
contains
function twice(x) result(y)
real(kind=wp), intent(in) :: x
real(kind=wp) :: y
y = 2*x
end function twice
end module m
program main
use m, only: wp, twice
integer :: i
real(kind=wp) :: x
i = 2
x = real(i, kind=wp)
print*,dsqrt(x)
print*,twice(dble(i))
! write the 2 lines above as the 2 lines below
print*,sqrt(x)
print*,twice(real(i, kind=wp))
end program main
2 Likes
How about some suggestions to copiously comment your code? I do some commercial remediation of code and not understanding what the code is trying to do makes it practically unmaintainable.
Commenting the source code properly and keeping the comments updated is definitely something to consider, in my opinion!
1 Like
Nice collection @alvrogd. I used to be a fervent advocate of the first recommendation,
- Ensure strict compliance with modern Fortran standards.
It only took me a month to realize that this recommendation cannot be followed while remaining productive unless there is a standardized Fortran preprocessor. On the positive side, the 202y standard will hopefully resolve many existing limitations that render this recommendation impractical.
2 Likes
Preprocessing has been around in Fortran circles for decades to add features Fortran doesn’t offer. This was especially true before Fortran offered proper structured programming constructs via commonly used pre-processors like FLECS, MORTRAN, and ratfor. And these days with Fortran-safe variants of the C pre-processor, fypp, and others. Sometimes at the end of the day, you do what you have to - until the language Standards catch up.
It is the same in the C/C++ world. Stroustrup hates pre-processors, but recognizes that sometimes they are helpful.
This is ironic since I think the first versions of C++ were implemented as cpp macros within C.
There are, of course, many uses for a preprocessor in actual codes. One of them is to “implement” new language features, either as a trial or as a quick-and-dirty hack. But another reason is to allow for machine dependent code, even when the various branches of that code are fully language-conforming but use various combinations of OS features and external libraries. This has characterized fortran codes since the fortran language was developed, which is why it is so perplexing that a fortran standard preprocessor has not been part of the standard language since the beginning.
I never delved into the details of the cfront preprocessor, so not sure how he actually implemented it.
A couple of Fortran features have mitigated the need for a preprocessor. Since we’ve had modules for over 30 years, they are generally better than using a preprocessor to #include header files. Of course Fortran has had a built-in include statement for as long. Longer if one counts the MIL-Spec extensions to Fortran 77. Perhaps now that C++ has modules, they’ll eventually move away from include files as well.
As we all know, Fortran 95 introduced coco. But no compiler vendor bothered to implement it, so none of us end-users could portably use it. Then they buried it, so none of us ever will. If something simple, I just rename my files to .F90 instead of .f90 and use the cpp-like directives. Otherwise I’ve been using fypp a lot lately.
Very early on in Stroustrups The C++ Programming Language (3rd edition), he advises “Macros are almost never necessary in C++”. Most of the use cases he suggests as C++ replacements in C code have Fortran equivalents. The big exception is templates…
Hello everyone,
Thank you all once again for your continued support and insights during our discussions!
We’re excited to announce the launch of a new GitHub repository: “Top 10 Recommendations for Fortran Modernization”. We believe this platform, as inspired by OWASP’s collaborative model, will not only preserve our discussions but also facilitate ongoing improvements and updates to the project.
In developing the initial set of “Top 10 Recommendations”, we focused on refining and narrowing down the most relevant actions and frequent suggestions from our discussions. The aim is to help guide future development efforts effectively.
As we finalize the content from this initiative for publication, we would also like to propose renaming the project to “Top 10 Fortran-lang Recommendations for Fortran Modernization”. This change would better reflect the extensive interaction and contributions of this community. Could you please share your thoughts on this new title, or suggest how we might formally seek the community’s approval?
We plan to regularly review and update the repository, expanding its contents with any incoming feedback and the latest developments in the Fortran community. We encourage everyone to visit the repository, participate in discussions, and contribute to the evolution of the “Top 10 Recommendations for Fortran Modernization”. Your ongoing input is invaluable for keeping this project dynamic and aligned with best practices in the field!
4 Likes