We’ve implemented filter and map operations. The results of both these operations are new arrays. Yet another common operation on arrays is the so-called reduction operation; we “reduce” multiple values to a single value. The most obvious example is calculating the sum of an array of integers: the input is an array (or list) and the output is a single integer:

pure function sum_all(numbers) result(res)
   integer, dimension(:), intent(in) :: numbers
   integer :: res

   integer :: i

   res = 0

   do i = 1, size(numbers)
      res = res + numbers(i)
   end do
end function sum_all

Just like with filter and map we can imagine a generalization of this process, which involves looping over the array elements and building up a single return value along the way. We start with the existing sum_all function. The first step is to let the user decide what the return value should be, which is the logic that happens inside the do loop. We extract a function for this:

In the previous post we looked at this dream scenario:

list([1, 3, 5, 7]) % filter(divisible_by(3)) % map(square)

As mentioned, we can’t chain function calls like this. But we can put intermediate results in local variables and achieve something similar:

integers = list([1, 3, 5, 7])
divisible_by_3 = integers%filter(divisible_by(3))
squared = divisible_by_3%map(square)

If the intermediate values are all the same type, we can reuse the variable:

integers = list([1, 3, 5, 7])
integers = integers%filter(divisible_by(3))
integers = divisible_by_3%map(square)

To enable this syntax, it’s clear that we need to introduce a derived type for a list of integers that has type-bound procedures filter and map. These functions should each return a new list, so we can call any of these functions again on the new list. Let’s start with an integer_list_t which contains an array of integers. We also provide a generic list interface with a specific procedure create_integer_list for creating the integer_list_t:

We considered the problem of filtering elements in an array, keeping only the ones we want. A decision about that is made by a function we pass as an argument.

A similar problem, but with its own challenges, is when we have an array of values and want to create a new array, with an equal number of elements, but each element has been transformed in some way. For instance, say we have an array of integers and want to square each integer. A procedural approach looks as follows:

We have a reusable filter function to which we pass the name of a procedure that matches a given interface. But can we also do something like this?

filter([1, 2, 3, 4], is_divisible_by(3))

Closures

This is a very common thing in functional programming. It involves something called higher-order functions. This means that a function may itself return a function. In this case, is_divisible_by returns a function that can be passed to filter. This returned function also needs to remember the value 3 that was passed to it. When it’s executed for each value in the integer array, it will check if that value is divisible by 3. In other languages such a function is called a closure; it’s a function that can be passed around as a value. Besides the function itself, it also has the data from the context where it was created - “bound” to it. In “ideal Fortran”, we would write something like this:

We have a working filter function for integers. Now can we generalize it? It would be nice if we could filter other types of arrays, like real arrays.

Generic filtering

As mentioned before, Fortran doesn’t have support for generics, which would allow you to use some kind of “placeholder” for types (e.g. [value_type]):

pure function filter(values, filter_func) result(res)
   [value_type], dimension(:), intent(in) :: values

   interface
      pure function filter_func(value) result(keep)
         implicit none(type, external)

         [value_type], intent(in) :: value
         logical :: keep
      end function filter_func
   end interface

   [value_type], dimension(:), allocatable :: res

   integer :: i

   res = pack(values, [(filter_func(values(i)), i=1, size(values))])
end function filter

You could then use filter on an array with any type of value, and the filter_func’s value argument would have to be of that same type, and the return type would be of that type too.

Once introduced to Fortran, we are left wondering what kind of language it really is. Traditionally, it’s been used as a procedural language, or a “Do this, do that” language as I’d like to call it. You can do some Object-Oriented programming with it, but it’s somewhat clunky, verbose, and not very “idiomatic”. (That’s not to say that you shouldn’t do it!) The same goes for Functional programming. If we’d like to write Fortran code that follows this paradigm, it becomes even more awkward. You’ll need several advanced techniques to make it work, and then there are still many limitations. The inability to chain function calls, the lack of tail call optimization and generic type-support, and the obstacles you have to conquer to get some kind of delayed execution; all of these sound like good reasons for not-even-trying…

In the previous post we properly encapsulated the integer level with a log_level_t derived type, achieving type safety.

Now, let’s consider the following feature request: we want to show the log level in front of the message. We could do it with decoration of course, but in the scope of this article, let’s do it in the log() subroutine directly. In this case we’re “lucky” that we can access the module-private data component level, so we can do a select case on it to determine what string should be printed:

In the previous post we introduced a derived type log_level_t. The type of data passed to the log() procedure is still an integer though:

subroutine log(message, level)
   character(len=*), intent(in) :: message
   integer, intent(in) :: level

   ! ...
end subroutine log

This doesn’t stop anyone from passing a completely meaningless integer value as the level argument to log().

Increasing type-safety

We’d like to increase type-safety and the way to do it is by using a more specific type. In our case, it would be great if we could use log_level_t as the argument type for level:

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:

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.