New #Fortran post: "Enumeration, part 2" https://matthiasnoback.nl/2025/06/fortran-enumeration-part-2/
We increase type safety by narrowing the integer level argument to a derived type argument. By introducing a factory type for log levels we are able to separate responsibilities. Finally we allow level comparisons using operator overloading.
[日常] 生成AIは『高級言語』の再来か？ - OHPとFORTRANの時代から探る、エンジニアの進化
https://qiita.com/ShigemoriMasato/items/fab875f7b7e9f07a01fc?utm_campaign=popular_items&utm_medium=feed&utm_source=popular_items
New #Fortran post: "Fortran: Enumeration, part 1" https://matthiasnoback.nl/2025/06/fortran-enumeration-part-1/
We are refactoring the integer parameters for the various log levels that we want to support. We want to accomplish type-safety and ease-of-use (pun intended).
In the post about decoration we declared log levels as follows: module logging_base ! ... integer, parameter, public :: LOG_DEBUG = 0 integer, parameter, public :: LOG_INFO = 1 integer, parameter, public :: LOG_WARN = 2 integer, parameter, public :: LOG_ERROR = 3 integer, parameter, public :: LOG_FATAL = 4 ! ... end module logging_base This is somewhat useful, but requires a dedicated only mention when importing each of these constants, which isn’t very nice: program main use logging_base, only: log, LOG_DEBUG, LOG_WARN ! ... call log('A debug message', LOG_DEBUG) ! ... call log('A warning', LOG_WARN) end program main Although we could live with that, the bigger issue remains: this is not a type-safe solution. Any integer may be passed as an argument for level, and the compiler wouldn’t warn us. For example:
Things I learned yesterday and today.
Python doesn't understand quadruple-precision real numbers. f2py will happily compile Fortran code containing real(16)s into a form that Python can talk to, but Python will segfault as soon as it receives one of those real(16)s.
Also, Fortran's built-in fraction function doesn't do what I thought it did.
New #Fortran post: "Module Design" https://matthiasnoback.nl/2025/06/fortran-module-design/
We look into splitting an existing module into smaller modules. We then put a façade module in front of the smaller modules, so users only have to deal with a simple programming interface. Finally we fix compilation cascade issues by introducing the concept of a submodule.
Fortran projects are famous for their large modules. Actually, we may also find very large files in legacy projects written in other languages, like Java, PHP, etc. These projects sometimes have files with thousands of lines of code. Fortran projects suffer more from large files I’d say, because: IDE support is not great. It’s often still hard to navigate to definitions or usages. There isn’t any support for automated refactorings, like extract function, move function, add parameter, etc. You often can’t get a clear overview of the structure/outline of a file. There are no strict indentation rules, making it easy to create a complete mess. Not everyone uses code formatting tools. Code formatting tools that exist and are used, aren’t always very good or easily configurable. Fortran code can be hard to read, partially because a lack of curly braces. It’s hard to visually recognize blocks of code. Another reason is that commonly there’s no distinction in letter casing between type names, function names, variable names, etc. Other languages may use CamelCase for types, CAPS for constants, pascalCase for methods, snake_case for functions, etc. In Fortran code, it’s all snake_case. If there’s anything we can do to make Fortran code easier to deal with, it’s to split the code into smaller parts. We need to have many more modules, each with distinct topics and concerns, so we can get a quick overview of the application’s domain and capabilities. Additionally, this will help us find the right place when we want to make changes to the code.
New #Fortran post: Service Composition, part 2: Decoration https://matthiasnoback.nl/2025/06/fortran-service-composition-decoration/
In this post we explore another way of composing abstractions, which is called decoration. We prefix existing log messages with a timestamp and implement optional delegation based on a configured log level.
In the previous post we saw how to use an abstraction to compose an aggregation of services of that same abstraction. There we simply delegated a call, adding no specific behavior. But we might as well add some new behavior before or after delegating the call. As an example, let’s try to implement a new feature in the logging module: we want to add a timestamp in front of each message, so the output becomes something like this:
#Fortran has joined the modern world: it has its own conference, #FortranCon.
Synopsis FortranCon 2025 is the third edition of the International Conference on the development and usage of the Fortran programming language, and it will take place on November 4-5, 2025. With this conference, we intend to bring together active Fortran project developers from all fields: library and tool developers as well as people using Fortran to develop scientific applications, to share their experience and exchange ideas. The event is organized with contributions by the community for...
📣 Back to the Fortran Future 2 📣
This satellite event takes place 8th September 2025 adjacent to RSECon25 (9-11th September 2025) at the University of Warwick.
Its free to attend, so if you have an interest in Scientific Fortran please consider joining us.
New #Fortran post "Fortran: Service Composition, part 1: Aggregation" https://matthiasnoback.nl/2025/06/fortran-service-composition-aggregation/
We are ready to build more features into the logging library, using different styles of composition. First we look at aggregation.
With our new service abstraction logger_t we are able to easily implement more features for our logger. We can do this without affecting current user code, because their code relies only on the abstraction, never on concrete implementations. A terminal output logger One thing we can do is define a second logger type, one that prints each message to the terminal output (stdout). Being a logger, it should also extend the abstract logger_t type, and provide an implementation for log():
New #Fortran post: "Abstract Types and Deferred Procedures" https://matthiasnoback.nl/2025/06/fortran-abstract-types-and-deferred-procedures/
We define an abstract type with deferred procedures (in OO language: an interface) for the file logger. Introducing an abstract factory allows clients to decouple from specific service types and shows us how polymorphism works.
With the new file_logger_t type we were able to model a logger service as a derived type. Now it’s time to make the service abstract. That is, to leave out the implementation detail that it’s a file logger (not a terminal output logger, etc.). Users should be able to use this abstract service to log any message, to whatever the application has been configured to log to. An abstract derived type Allowing a user to depend on an abstract service requires the use of an abstract type. The user can import this abstract type in their module or program. Meanwhile, the factory function for the abstract logger will actually return the concrete file logger, which extends the abstract logger. For object-oriented programmers this may be a familiar approach, but it’s not a very common Fortran practice. In code it looks as follows:
Matthias Noback
Qiita - 人気の記事
Infrapink (he/his/him)
Konrad Hinsen
Society of RSE