What I Miss When Writing Fortran

I work in a number of different languages depending on the project. For rapid prototyping I use Jupyter Notebook with Python 2 or 3 which is then converted to standalone code, documents are written in Markdown or LaTeX and compiled to HTML or PDF, Fortran is used for heavy computation, etc. I also revitalize a lot of legacy FORTRAN IV and FORTRAN77 code so I frequently find myself wishing I had the capabilities found in the standard libraries of more modern languages. I also miss certain language-specific development tools which don’t have a Fortran equivalent.

I spent a little time assembling a sizable library and tool wishlist:

Standard Libraries

• Logging
• Searching and sorting
• Testing tools, frameworks for unit & integral testing
• Associative arrays (hash, dict)
• Argument defaults
• Units of measure
• Command-line option and argument processing
• Metadata (data pedigree, date, version, references to source)
• Ability to read/write common text file formats (columnar/CSV, ini, JSON, HTML, XML)
• Basic filesystem tools (mkdir, chdir,rmdir, glob, dirlist, basename, Python’s os.path functions)
• Database access (sqlite)
• Object (de)serialization
• eval-like variable assignment (a kinder, gentler, usable namelist)
• Regular expressions (PCRE)
• Basic text manipulation functions (split, atoi, atof, sprintf, ucase, lcase, startswith, endswith,  substring detection, a proper trim function)
• Constrained reals; for example, absolute mass, pressure, or temperature variables which throw an exception if they become negative. This is a first-class feature of types in Ada (constrained subtype)
• Range functions; detect if a value is within a range (inclusive/exclusive of endpoints), coerce a variable to be within a range (clamping), generate a range (linear, log, Chebyshev nodes)

Tools

• Refactoring tools (Photran refactoring tools but standalone and not integrated with Eclipse)
  • Explicit declaration tools for enforcing IMPLICIT NONE
  • Changing case of keywords and variables
  • Minimizing use imports
  • Conversion of IF/GOTO to IF/THEN/ELSE or SELECT/CASE
• Idiom analyzer (like C’s lint, Python’s pylint and flake8, Perl’s perlcritic)
  • Check intent
  • Flag deprecated constructs (COMMON, EQUIVALENCE, ENTRY, GOTO, ASSIGN, alternate returns, Hollerith formats, etc.)
  • CYCLE and EXIT detection
  • Detect implicit persistence or SAVE
• Flexible source code reformatter/pretty-printer (like HTML’s tidy, and Perl’s perltidy)
• Project scaffolding (like Python’s pyscaffold or cookiecutter, Rust’s  cargo, and Perl’s Module::Build)

Note that I have avoided much talk of mathematical libraries like BLAS or LAPACK since those are rarely my pain points in Fortran development. The main numerical features I’d like are a few  convenience functions, mostly dealing with ranges of values:

I have found a few libraries from the FLIBS toolkit which meet my needs, specifically for testing and logging.

What I Use

• doxygen does a pretty decent job of generating developer documentation directly from source code. Doxygen has a few quirks (it only supports free-format Fortran) but I especially like that it uses LaTeX for PDF rendering and it supports mathematical typesetting which is important in documenting numerical and scientific code. I tried using ford but it expected comments to be located in a different place than doxygen which made it inconvenient to test at the time; I have no opinion of it but I wanted to give it some credit.
• findent; I’ve tried f2f.pl, Michael Metcalfe’s convert.f90, and other tools and findent is the best one I’ve found so far. findent is written in C++ and uses a recursive descent parser. I have suggested improvements and the author was very receptive.
• FLIBS is Arjen Markus’ suite of Fortran modules and utilities. It has many features which I would like from a standard library. Two are
  • m_multilog, a logging library which filters log entries into multiple files or to standard output (screen) as appropriate, and
  • ftnunit, a unit testing framework which can be embedded into your Fortran application.
• Photran, part of the Eclipse Parallel Tools Project. This does a lot of refactoring but is limited to use within Eclipse. While Eclipse and Photran are free, the refactoring tools can’t easily be extracted into standalone utilities which limits their ongoing maintenance and widespread usage.
• CMake, a multi-platform build framework. Along with CPack and CTest, CMake is part of a widely-used toolkit to (theoretically at least) allow one to compile, test, and package an application for distribution from a single source code archive

CMake is rather uncomfortable to use and I did not find the documentation as clear as I would have liked. I eventually built a working CMake setup for a moderately complex Fortran application and successfully built code using both gfortran and ifort on Linux. I had difficulty getting CMake to work with ifort on Windows which limited its utility, though the problem was likely due to the old version of Visual Studio I was using at the time. So while I’m using CMake at present, I could be convinced to use a different system provided it a) worked on multiple platforms, and b) was used by more than 3 other people. I know of at least 5 different competing cross-platform build systems, the combined total of which do not match the uptake of CMake.

I have also built a few custom error parsers/filters in Perl for detecting and writing declarations for undeclared variables and writing usestatements to import variables from other modules. These are of limited utility since they rely on Intel Fortran error messages. I developed these scripts before the Photran refactoring tools were released; I would strongly suggest using Photran instead.

Since I have recently been writing about a creating a Hypothetical Fortran Standard Library, I thought it would be helpful to list the capabilities I would like and some of the tools I currently use. Consider this a starting point for discussion.