Fortran Wiki
Better support for COMMON blocks
Proposal
Lift all of the restrictions that prevent objects from being contained in COMMON blocks. In most cases, there is no really good reason to restrict global objects, such as pointers. from being contained in a COMMON block.
The rationale for the restrictions seems to work towards deprecating COMMON blocks in favor of MODULEs. However, MODULEs carry many complications (e.g, .mod files and dependency cascades). Often, it is far easier just to use a COMMON block and avoid MODULEs.
Sub-modules fix many of the annoyances of modules, but why not keep fully functional COMMON blocks? If COMMON blocks are head toward deprecation, then some sort of non-module global support is needed.
Alternatives
It may actually be better to support global variables outside of a module. Then, a COMMON could be just one type of non-module global, and the Fortran objects excluded from COMMONs could be made accessible directly as globals.
A good alternative is to define a derived-type data structure, and make it accessible as a global variable. Fortran does not support native globals outside of modules (maybe it should?), but a global could be made accessible via a function that returns a pointer to the global data.
Why not just use modules? Fortran90 was designed to support both module and non-module interfaces. Although non-module approach has been largely neglected, it can be useful at times.
Comments
Ralph Johnson Can you give an example of when modules are not as good as COMMON? I have always thought that a module that contained only variables, and made them all exportable, was pretty much the same, so COMMON was not needed.
Joe Krahn Fortran90 was designed so that modules are optional (e.g. you can write INTERFACE blocks and define derived types in an include file). With that approach, common blocks are still important.
So, why avoid modules? It is probably mostly relevant to including a few modern features into existing Fortran77 code. Here is my story: I spent some time updating some Fortran77 code using include files to define common blocks, replacing them with modules. The result was a massive slowdown in compile time, not to mention having to deal with .mod file dependencies. Modules are slow because the compiler developers work with module-based code, so USEing modules with every procedure is not the norm, end becomes very slow. So, I moved procedures into modules. That required extra work to re-divide source files so there are no circular call dependencies. Then, I ran into troubles for procedures that require intentionally mismatched argument types for complex-to-real FFTs, and work arrays. In the end, the modules just added extra complexity, compile time and new bugs to track down, so I deleted the whole mess and went back to COMMON blocks.
Ian Harvey “Most” of the prohibitions on things in COMMON appear to be because incorporating that thing would conflict badly with storage association or be a severe restriction on implementations. Note also that Fortran pointers can be in COMMON. Given that, the second sentence seems a bit subjective.
What are the specific things that are prohibited from being in COMMON that you would like to see allowed?
I agree that taking old code which makes extensive use of named common blocks and converting it all to modules can be very time-consuming and difficult, and so in some cases not worth-while. But I don’t agree that it is useful to retain COMMON in the language except for compatibility with old code. It seems to me that using MODULES is always neater, simpler, and safer in newly written code. I particularly value the type-checking of actual and dummy arguments of procedures which are used via USE statements; with COMMON blocks it is entirely valid to have different names in different program units, and there is essentially no type checking at all.