traits.tex

\documentclass[11pt,oneside]{report}
\usepackage[a4paper, total={6.5in, 9in}]{geometry}
\usepackage{url}
\usepackage{listings}
\usepackage{listings-rust}
\usepackage[scaled=0.82]{beramono}
\usepackage[T1]{fontenc}
\usepackage{hyperref}
\usepackage{xcolor}
\usepackage[title]{appendix}
\usepackage{mathpazo}
%\usepackage{mathptmx}
\usepackage{array}
\usepackage{booktabs}
\usepackage{tablefootnote}
\usepackage[autostyle]{csquotes}
\usepackage[
	backend=biber, 
	bibstyle=numeric,
	citestyle=numeric, 
	sorting=nyt,
	sortcites=true, 
	abbreviate=false, 
	defernumbers=true,
]{biblatex}
\defbibheading{bibempty}{}

\addbibresource{traits.bib}

\newcolumntype{R}[1]{>{\raggedleft\arraybackslash}p{#1}} 
\newcolumntype{L}[1]{>{\raggedright\arraybackslash}p{#1}} 
\newcolumntype{C}[1]{>{\centering\arraybackslash}p{#1}}

\newcommand{\code}[1]{{\selectfont\ttfamily{#1}}}

\lstdefinelanguage{LFortran}[]{Fortran}{
  morekeywords={abstract,import,class,type,typeof,typedef,
    deferred,pass,nopass,static,extends,implements,sealed,
    associate,generic,initial,init,itself,real32,real64}
}

\lstdefinelanguage{Swift6}[]{Swift}{
  morekeywords={any}
}

\hypersetup{
    colorlinks,
    linkcolor={blue!70!black},
    citecolor={blue!70!black},
    urlcolor={blue!70!black}
}

\frenchspacing

\begin{document}

\title{\textbf{Traits, Generics, and Modern-day OOP for Fortran}}

\author{Konstantinos Kifonidis, Ondrej Certik, Derick Carnazzola}

\maketitle

\abstract{Based on conclusions drawn from a survey of modern
  languages, a traits system for Fortran is developed that allows for
  the uniform expression of run-time and compile-time polymorphism in
  the language, and thus for the uniform management of source code
  dependencies on user-defined and language-intrinsic types. The
  feature set that is described here is small enough to facilitate a
  first prototype implementation in an open source compiler (like
  LFortran, LLVM Flang, or GNU Fortran), but at the same time
  comprehensive enough to already endow Fortran with polymorphic
  capabilities that widely equal those of modern programming languages like
  Swift, Rust, Go, Carbon, or Mojo. The discussed extensions are fully
  backwards compatible with present Fortran, and enable modern-day,
  traits-based, object-oriented programming, and powerful, easy to
  use, fully type-checked, generics. The latter support seamlessly
  both the procedural, functional, and object-oriented programming
  styles, and they largely get by \emph{without} requiring manual
  instantiations by the user. The presented design could also be
  naturally extended to support rank-genericity for arrays, structural
  subtyping, and compile-time polymorphic union/sum types. Its modern
  capabilities are expected to transform the way both Fortran
  applications and libraries will be written in the future. Decoupled
  software plugin architectures with enormously improved source code
  flexibility, reusability, maintainability, and reliability will
  become possible, without any need for run-time type inspections, and
  without any loss in computational performance.}


\chapter{Introduction}

Polymorphism was discovered in the 1960ies by Kristen Nygaard and
Ole-Johan Dahl during their development of Simula~67, the world's
first object-oriented (OO) language \cite{Dahl_04}. Their work
introduced into programming what is nowadays known as ``virtual method
table'' (i.e. function-pointer) based run-time polymorphism, which is
both the first focus of this document, and the decisive feature of all
OO languages. Several other forms of polymorphism are known today, the
most important of them being parametric polymorphism
\cite{Cardelli_Wegner_85}, also known as ``generics'', which is the
second focus of this document, and which has historically developed
disjointly from run-time polymorphism since it makes use of
compile-time mechanisms.

\section{The purpose of polymorphism}

But what is the purpose of polymorphism in a programming language?
What is polymorphism actually good for? One of the more comprehensive
answers to this question was given by Robert C. Martin in numerous
books (e.g. \cite{Martin_17}), as well as in the following quotation
from his blog \cite{Martin_14}:

\begin{displayquote}
``There really is only one benefit to polymorphism; but it's a big
  one. It is the inversion of source code and run time dependencies.

  In most software systems when one function calls another, the
  runtime dependency and the source code dependency point in the same
  direction. The calling module depends on the called module. However,
  when polymorphism is injected between the two there is an inversion
  of the source code dependency. The calling module still depends on
  the called module at run time. However, the source code of the
  calling module does not depend upon the source code of the called
  module. Rather both modules depend upon a polymorphic
  interface.

  This inversion allows the called module to act like a
  plugin. Indeed, this is how all plugins work.''
\end{displayquote}

Notice the absence of the words ``code reuse'' in these statements.
The purpose of polymorphism, according to Martin, is the ``inversion''
(i.e. replacement, or management) of rigid source code dependencies by
means of particular abstractions, i.e. polymorphic interfaces (or
proto\-cols/traits, as they are also known today). The possibility to
reuse code is then merely the logical consequence of such proper
dependency management in a polymorphism-based software plugin
architecture.

\section{Source code dependencies in statically typed languages}

Which then are the source code dependencies that polymorphism helps us
manage? It has been customary to make the following distinction when
answering this question:
\begin{itemize}
\item
  Firstly, most larger programs that are written in statically typed
  languages (like Fortran) have dependencies on user-defined
  procedures and data types. If the programmer employs encapsulation
  of both a program's procedures and its data, i.e. its state, both
  these dependencies can actually be viewed as dependencies on
  \emph{user-defined abstract data types}. These are the dependencies
  that Martin is concretely referring to in the above quotation, and
  it is these dependencies on (volatile) user-defined data and
  implementations that are particularly troublesome, because they lead
  to rigid coupling between the various different \emph{parts} of an
  application. Their results are recompilation cascades, the
  non-reusability of higher-level source code units, the impossibility
  to comprehend a large application incrementally, and fragility of
  such an application as a whole.
\item
  Secondly, every program, that is written in a statically typed
  language, also has dependencies on abstract data types that are
  provided by the language itself. Fortran's \code{integer},
  \code{real}, \code{complex}, etc., intrinsic types are examples of
  \emph{language-intrinsic abstract data types}. While hard-wired
  dependencies on such intrinsic types do not couple different parts
  of a program (because the implementations of these types are
  supplied by the language), they nevertheless make a program's source
  code rigid with respect to the data that it can be used on.
\end{itemize}

The most widely used approaches to manage dependencies on
language-intrinsic types have so far been through generics, while
dependency management of user-defined (abstract data) types has so far
been the task of OO programming and OO design patterns. Martin
\cite{Martin_17} has, for instance, defined object-orientation as
follows:

\begin{displayquote}
  ``OO is the ability, through the use of polymorphism, to gain
  absolute control over every source code dependency in [a software]
  system. It allows the architect to create a plugin architecture, in
  which modules that contain high-level policies are independent of
  modules that contain low-level details. The low-level details are
  relegated to plugin modules that can be deployed and developed
  independently from the modules that contain high-level policies.''
\end{displayquote}

\section{Modern developments}

Notice how Martin's modern definition of object-orientation, that
emphasizes source code decoupling, is the antithesis to the usually
taught ``OO'' approaches of one class rigidly inheriting
implementation code from another. Notice also how his definition does
not require some specific type of polymorphism for the task of
dependency management, as long as (according to Martin's first
quotation) the mechanism is based on polymorphic interfaces.

Martin's statements on the purpose of both polymorphism and OO simply
reflect the two crucial developments that have taken place in these
fields over the last decades. Namely, the realizations that
\begin{itemize}
\item
  run-time polymorphism should be freed from the conflicting concept
  of implementation inheritance (to which it was originally bound
  given its Simula~67 heritage), and be formulated exclusively in
  terms of conformance to polymorphic interfaces, i.e. function
  signatures, or purely procedural abstractions, and that
\item
  compile-time polymorphism should be formulated in exactly the same
  way as well.
\end{itemize}

These two developments, taken together, have recently opened up the
possibility to treat polymorphism, and hence the dependency management
of both user-defined and language-intrinsic types, uniformly in a
programming language. As a consequence, it has become possible to use
the potentially more efficient (but also less flexible) mechanism of
compile-time polymorphism also for certain tasks that have
traditionally been reserved for run-time polymorphism (in the form of
OO programming), and to mix and match the two polymorphism types
inside a single application to better satisfy a user's needs for both
flexibility and efficiency.

\section{Historical background}

The road towards these realizations was surprisingly long. Over
the last five decades, a huge body of OO programming experience first
had to demonstrate that the use of (both single and multiple)
implementation inheritance breaks encapsulation in OO languages, and
therefore results in extremely tightly coupled, rigid, fragile, and
non-reusable code. This led to an entire specialized literature on OO
design patterns \cite{Gamma_et_al_94,Martin_03,Holub_04}, that aimed
at avoiding such rigidity by replacing the use of implementation
inheritance with the means to formulate run-time polymorphism that are
discussed below. It also led to the apprehension that implementation
inheritance (but \emph{not} run-time polymorphism) should be abandoned
\cite{Weck_Szyperski}. In modern languages, implementation inheritance
is either kept solely for backwards compatibility reasons (e.g. in the
Swift and Carbon languages), or it is foregone altogether (e.g. in
Rust, and Go).

The first statically typed mainstream programming language that
offered a proper separation of run-time polymorphism from
implementation inheritance was Objective-C. It introduced
``protocols'' (i.e. polymorphic interfaces) in the year 1990
\cite{Cox_et_al_20}. Protocols in Objective-C consist of pure function
signatures, that lack implementation code. Objective-C provided a
mechanism to implement multiple such protocols by a class, and to thus
make classes conform to protocols. This can be viewed as a restricted
form of multiple inheritance, namely inheritance of object
\emph{specification}, which is also known as \emph{subtyping}.

Only a few years later, in 1995, the Java language hugely popularized
these ideas using the terms ``interfaces'' and ``interface
inheritance'' \cite{Cox_et_al_20}. Today, nearly all modern languages
support polymorphic interfaces/protocols, and the basic mechanism of
multiple interface inheritance that was introduced to express run-time
polymorphism in Objective-C, often in even improved, more flexible,
manifestations. The only negative exceptions in this respect being
modern Fortran, and C++, which both still stick to the obsolescent
Simula~67 paradigm.

A similarly lengthy learning process, as that outlined for run-time
polymorphism, also took place in the field of compile-time/parametric
polymorphism. Early attempts, notably templates in C++, to render
function arguments and class parameters polymorphic, did not impose
any constraints on such arguments and parameters, that could be
checked by C++ compilers. With the known results on compilation times
and cryptic compiler error messages
\cite{Haveraaen_et_al_19}. Surprisingly, Java, the language that truly
popularized polymorphic interfaces in OO programming, did not provide
an interface based mechanism to constrain its generics. Within the
pool of mainstream programming languages, this latter realization was
only made with the advent of Rust \cite{Matsakis_2014}.

Rust came with a traits (i.e. polymorphic interfaces) system with which
it is possible for the user to uniformly and transparently express
both generics (i.e. compile-time) and run-time polymorphism in the
same application, and to relatively easily switch between the two,
where possible. Rust's traits are an improved form of
protocols/interfaces in that the user can implement them for a type
without having these implementations be coupled to the type's actual
definition. Thus, existing types can be made to retroactively
implement new traits, and hence be used in new settings (with some
minor restrictions on user ownership of either the traits or the
types).

Rust's main idea was quickly absorbed by almost all other mainstream
modern languages, most notably Swift, Go, and Carbon, with the
difference that these latter languages tend to leave the choice
between static and dynamic binding of procedures to the compiler, or
language implementation, rather than the programmer. C++ is in the
process of adopting generics constraints for its ``templates'' under
the term ``strong concepts'', but without implementing the greater
idea to uniformly express \emph{all} the polymorphism in the language
through traits. An implementation of this latter idea must today be
viewed as a prerequisite in order to call a language design
``modern''. The purpose of this document is to describe extensions to
Fortran, that aim to provide the Fortran language with such modern
capabilities.


\chapter{Case study: Calculating the average value of a numeric array}

To illustrate the advanced features and capabilities of some of the
available modern programming languages with respect to polymorphism,
and hence dependency management, we will make use here of a case
study: the simple test problem of calculating the average value of a
set of numbers that is stored inside a one-dimensional array. In the
remainder of this chapter, we will first provide an account and some
straightforward monomorphic (i.e. rigidly coupled) functional
implementation of this test problem, followed by a functional
implementation that makes use of both run-time and compile-time
polymorphism to manage rigid source code dependencies. In the survey
of programming languages that is presented in
Chapter~\ref{chapt:survey}, we will then recode this standard test
problem in an encapsulated fashion, to highlight how the source code
dependencies in this problem can be managed in different languages
even in more complex situations, that require OO techniques.

\section{Monomorphic functional implementation}
\label{sect:mono_functional}

We have chosen Go here as a language to illustrate the basic ideas.
Go is easily understood, even by beginners, and is therefore well
suited for this purpose (another good choice would have been the Swift
language). The code in the following Listing~\ref{lst:funcGo} should
be self explanatory for anyone who is even only remotely familiar with
the syntax of C family languages. So, we'll make only a few remarks
regarding syntax.
\begin{itemize}
\item
  While mostly following a C like syntax, variable declarations in Go
  are essentially imitating Pascal syntax, where a variable's name
  precedes the declaration of the type.
\item
  Go has two assignment operators. The usual \code{=} operator, as it
  is known from other languages, and the separate \code{:=} operator,
  that employs automatic type inference for combined declaration and
  initialization of a variable.
\item
  Go has array slices that most closely resemble those of Python's
  Numpy (which exclude the upper bound of an array slice).
\end{itemize}

Our basic algorithm for calculating the average value of an array of
integer elements employs two different implementations for
averaging. The first makes use of a ``simple'' summation of all the
array's elements, in ascending order of their array index. While the
second sums in a ``pairwise'' manner, dividing the array in half to
carry out the summations recursively, and switching to the ``simple''
method once subdivision is no longer possible. In both cases, the
resulting sum is then divided by the array's number of elements, to
obtain the desired average.

\lstinputlisting[language=Go,style=boxed,label={lst:funcGo},caption={Monomorphic functional version of the array averaging example in Go.}]{Code/Go/coupled.go}

An inspection of Listing~\ref{lst:funcGo} will readily reveal that
this code has three levels of rigid (i.e. hard-wired)
dependencies. Namely,
\begin{enumerate}
\item
  function \code{pairwise\_sum} depending on function
  \code{simple\_sum}'s implementation,
\item
  functions \code{simple\_average} and \code{pairwise\_average}
  depending on functions' \code{simple\_sum} and \code{pairwise\_sum}
  implementations, respectively, and
\item
  the entire program depending rigidly on the \code{int32} data type in
  order to declare both the arrays that it is operating on, and
  the results of its summation and averaging operations.
\end{enumerate}
The first two items are dependencies on user-defined implementations,
while the third is a typical case of rigid dependency on a
language-intrinsic type, which renders the present code incapable of
being applied to arrays of any other data type than
\code{int32}s. Given that we are dealing with three levels of
dependencies, three levels of polymorphism will accordingly be
required to remove all these dependencies.

\section{Polymorphic functional implementation}
\label{sect:poly_functional}

Listing~\ref{lst:polyfuncGo} gives an implementation of our test
problem, that employs Go's generics and functional features to
eliminate the last two of the rigid dependencies that were listed in
Sect.~\ref{sect:mono_functional}. The code makes use of Go's generics
to admit arrays of both the \code{int32} and \code{float64} types as
arguments to all functions, and to express the return values of the
latter. It also makes use of the run-time polymorphism inherent in
Go's advanced functional features, namely closures and variables of
higher-order functions, to replace the two previous versions of
function \code{average} (that depended on specific implementations),
by a single polymorphic version. Only the rigid dependency of function
\code{pairwise\_sum} on function \code{simple\_sum} has not been
removed, to keep the code more readable. In the OO code
versions, that will be presented in Chapter~\ref{chapt:survey}, even
this dependency is eliminated.

A few remarks are in order for a better understanding of
Listing~\ref{lst:polyfuncGo}'s code:
\begin{itemize}
\item
  In Go, generic type parameters to a function, like the parameter
  \code{T} here, are provided in a separate parameter list, that is
  enclosed in brackets [ ].
\item
  Generic type parameters have a constraint that follows their
  declared name. Go exclusively uses interfaces as such constraints
  (like the interface \code{INumeric} in the following code).
\item
  Interfaces consist of either explicit function signatures, or
  \emph{type sets}, like \code{int32 | float64} in the present
  example. The latter actually signify a set of function signatures,
  too, namely the signatures of the intersecting set of all the
  operations and intrinsic functions for which the listed types
  provide implementations.
\item
  The code makes use of type conversions to the generic type \code{T},
  where required. For instance, \code{T(0)} converts the (typeless)
  constant \code{0} to the corresponding zero constant of type
  \code{T}.
\item
  The code instantiates closures and stores these by value in two
  variables named \code{avi} and \code{avf} for later use (Fortran
  and C programmers should note that \code{avi} and \code{avf} are
  \emph{not} function pointers!).
\end{itemize}

\lstinputlisting[language=Go,style=boxed,label={lst:polyfuncGo},caption={Polymorphic functional version of the array averaging example in Go.}]{Code/Go/functional.go}

Notice how, in order to instantiate the closures \code{avi} and
\code{avf} (see the \code{switch} statement), manual instantiations of
the \code{simple\_sum} and \code{pairwise\_sum} generic functions are
required -- with the arguments \code{int32} or \code{float64} being
substituted for the generic type parameter, \code{T}, of these
functions.

The motivation to code the example as in Listing~\ref{lst:polyfuncGo}
is that once the two closures, \code{avi} and \code{avf}, are
properly instantiated, they could then be passed from the main program
to any other client code that would need to make use of the particular
averaging algorithm that was selected by the user. This latter client
code would \emph{not} have to be littered with \code{switch}
statements itself, and it would \emph{not} have to depend on any
specific implementations. It would merely depend on the closures'
interfaces. The same holds for the OO code versions that are discussed
in the next chapter, with objects replacing the closures (both being
merely slightly different realizations of the same idea).


\chapter{Survey of modern languages}
\label{chapt:survey}

In the present chapter, we give encapsulated (i.e. OO) code versions
of the test problem in various modern languages. As in the functional
code version that was presented in Sect.~\ref{sect:poly_functional},
we employ run-time polymorphism to manage the dependencies on
user-defined implementations (in this case abstract data types), and
generics in order to manage the dependencies on language-intrinsic
types. This serves to illustrate how both run-time and compile-time
polymorphism can be typically used for dependency management in an OO
setting in these modern languages. The survey also aims to highlight
the many commonalities but also some of the minor differences in the
approaches to polymorphism that were taken in these different
languages. As a final disclaimer, we do not advocate to code problems
in an OO manner that can be easily coded in these languages in a
functional way (as it is the case for this problem). However, in more
complex cases, where many more nested functions would need to be used,
and where state would have to be hidden, the OO programming style
would be the more appropriate one. Hence, our test problem will stand
in, in this chapter, for emulating such a more complex problem, that
would benefit from the OO coding style.

\section{Go}

Go has supported run-time polymorphism through (polymorphic)
``interfaces'' (and thus modern-day OO programming) since its
inception. In Go, encapsulation is done by storing state in a
\code{struct} and by binding procedures, that need to use that
state, to this same \code{struct}. Thereby creating a user-defined
abstract data type (or ADT) with methods. Go allows the programmer to
implement multiple polymorphic interfaces for such a type (i.e. to use
multiple interface inheritance), even though it offers no explicit
language statement for this purpose.

Instead, a user-defined type is implicitly assumed to implement an
interface whenever it provides implementations of all the interface's
function signatures. This structural way of implementing interfaces
also merely requires an object reference of the type to be passed to
its methods (by means of a separate parameter list, in front of a
method's actual name). It is otherwise decoupled from the type's
(i.e. the ADT's \code{struct}) definition. Go, finally, makes it
explicit in its syntax that interfaces (like \code{struct}s) are types
in their own right, and that hence polymorphic variables
(i.e. objects) can be declared in terms of them.

Restrictions in Go are that language-intrinsic types cannot have
user-provided methods, and that methods and interfaces cannot be
directly implemented for user-defined types whose definitions are
located in other packages. That is, the programmer has to write
wrappers in the latter case.

Since version 1.18, Go also supports compile-time polymorphism through
generics. Go's generics make use of ``strong concepts'', since they
are bounded by constraints that are expressed through
interfaces. Hence, the Go compiler will fully type-check generic code.
In Go, structures, interfaces, and functions, but not methods, can all
be given their own generic type parameters.

\subsection{Encapsulated version coded in Go}
\label{sect:Go_encapsulated}

Listing~\ref{lst:OOGo} gives an encapsulated version of the test
problem coded in Go. The two different implementations of the
\code{sum} function have been encapsulated in two different ADTs named
\code{SimpleSum} and \code{PairwiseSum}, whereas a third ADT named
\code{Averager} encapsulates the functionality that is required to
perform the actual averaging. The latter two ADTs contain the
lower-level objects \code{other} and \code{drv} of \code{ISum[T]} type
as components, to which they delegate calls to these objects'
\code{sum} methods. Notice, how the use of the polymorphic interface
\code{ISum[T]}, for the declarations of these objects, enables them to
be initialized with either \code{SimpleSum} or \code{PairwiseSum}
instances.

A second interface, named \code{IAverager}, is used to enable
polymorphism for different averaging algorithms. Finally, there's a
third interface, \code{INumeric}, that serves exactly the same purpose
as in the functional polymorphic version that was given in
Sect.~\ref{sect:poly_functional}, namely to make all function
arguments and return values polymorphic, by admitting as input and
output parameters both the \code{int32} and \code{float64} intrinsic
types.

Hence, three polymorphic interfaces were required in this code, to
eliminate the three levels of rigid dependencies that were listed in
Sect.~\ref{sect:mono_functional}. Notice also that, exempting
\code{INumeric}, all the interfaces and all the user-defined ADTs need
to take in generic type parameters in this example. In Go, this is
required to enable all the \code{sum} and \code{average} methods to
use such generic type parameters.

\lstinputlisting[language=Go,style=boxed,label={lst:OOGo},caption={Encapsulated Go version of the array averaging example.}]{Code/Go/mixed.go}

The main program makes use of Go's built-in structure constructors,
and chaining of their calls, to instantiate objects of the
required ADTs. In particular, it instantiates run-time polymorphic
\code{Averager} objects (depending on whether simple or pairwise sum
averaging is to take place), and it does so for both the \code{int32}
and \code{float64} types separately, to then use these
objects on \code{int32} and \code{float64} data, respectively.

That \emph{two} such objects are required (one for each
language-intrinsic data type) is connected to the aforementioned fact
that in order to make methods use generic type parameters in Go, one
has to parameterize interfaces, and instantiate these with different
actual data types, as in \code{func main}'s first two code lines. A
single (i.e. unparameterized) \code{IAverager} interface therefore
doesn't suffice, which is unfortunate from the user's perspective, as
some code duplication in client code cannot be avoided in this way.

It should also be noted, that Go's intuitive way of expressing the
generics constraints of interface \code{INumeric} in terms of a type
set, besides having obvious advantages in terms of code clarity and
conciseness, comes also at a price. Namely its only \emph{partial}
conformance to the Open/Closed Principle (OCP) of OO programming
\cite{Martin_OCP}. The latter principle demands that only new code be
added to an application for extending its functionality, and any
already written code to not be changed.

It can be seen, from Listing~\ref{lst:OOGo}, that this principle can
only be partly, but not strictly (i.e. fully), complied with in
generic object-oriented Go code. Because for the programmer to make
this listing work also with, e.g., the \code{float32} type, he would
have to add this type to the type set of interface \code{INumeric},
and to thus touch already written code. Notice, though, that
\emph{none} of the implementation code of Listing~\ref{lst:OOGo} would
be affected. Only the interface \code{INumeric} would need to be
changed, that the remaining client code depends upon as a generics
constraint.

If the client code were distributed among different packages or
modules, the consequences of such a (weak) violation of the OCP would
be confined to the occurrence of a recompilation cascade in the
dependent modules. In actual practice, one may quite often regard this
as an acceptable (minor) inconvenience, rather than a fundamental
maintenance issue -- especially in situations where the need to add
new types is a relatively rare one.

\section{Rust}

Like Go, Rust supports both run-time and compile-time polymorphism
through polymorphic interfaces, which Rust calls ``traits''. Unlike
Go, Rust has its programmers implement traits in a nominal manner, by
using explicit \code{impl} code blocks to provide a trait's method
implementations. These same \code{impl} blocks can also be used to
bind so-called ``associated functions'' to a type, which aren't
methods, i.e. which don't take in a \code{self} (passed-object dummy)
argument. A typical example for this are user-defined
constructors. See the functions that are named \code{new} in the
following code Listing~\ref{lst:OORust}, and are called using
\code{::} syntax.

In contrast to Go, Rust allows the programmer to implement traits for
both user-defined \emph{and} language-intrinsic types, and to do so
for types that are located in external libraries (called ``crates'' in
Rust), as long as the traits themselves are defined in the
programmer's own crate. The reverse, namely implementing an external
trait for a user-owned type, is also possible. Only the (edge) case of
implementing an external trait for an external type is not allowed
(this is called the ``orphan rule'' \cite{Klabnik_Nichols}). The
latter case requires the use of wrappers.

Comparable to Go, Rust's generics model allows for the generic
parameterization of functions, traits, and user-defined types like
\code{struct}s. Rust does not explicitly forbid generic
methods. However, if one defines such a method's signature within a
trait, then this will make the trait unusable for the declaration of
any ``trait objects'' \cite{Lyon}, i.e. for the employment of run-time
polymorphism. Thus, the Rust programmer will in general (need to)
parameterize traits and \code{struct}s rather than any methods
themselves. Rust generics are fully type-checked at compilation time,
i.e. Rust supports ``strong concepts''.

\subsection{Encapsulated version coded in Rust}
\label{sect:OORust}

The encapsulated Rust version of our test problem, that is given in the
following Listing~\ref{lst:OORust}, is in its outline quite similar to
the corresponding Go version\footnote{Notice that the present Rust
version makes universal use of dynamic method dispatch via trait
objects, to correspond most closely to all the other
implementations that we provide in both the present chapter, and in
Sect.~\ref{sect:Fortran_dynamic_dispatch}. An alternative, more
idiomatic, Rust version that is equivalent to the Fortran version
which we'll give in Sect.~\ref{sect:Fortran_static_dispatch}, and that
effects static dispatch of the various \code{sum} methods through the
use of generics, can be found in the \code{Code} subdirectory that is
accompanying this document.}. There are, however, a few differences,
that are listed in the following notes, and in our concluding remarks.

\begin{itemize}
\item
  Rust uses angled brackets, \code{< >}, to indicate generic parameter
  lists.
\item
  Generics constraints in Rust are typically enforced by specifying
  the required traits in \code{impl} blocks using \code{where}
  statements.
\item
  Rust does not offer an equivalent to Go's type set syntax and
  semantics. In order to enable numeric operations on generic types,
  Rust instead provides a \code{Num} trait via an external \code{num}
  crate (i.e. library). However, the use of this external dependency
  makes available neither the \code{AddAssign} (\code{+=}) operator,
  nor casts to generic types within generic routines (as they are
  provided in Go).
\item
  Since the employed algorithm relies on these features, the following
  code uses a homemade \code{INumeric} trait, that derives from Rust's
  \code{Num} and \code{AddAssign} traits, and extends them by the
  requirement to also implement a constructor via an associated
  function, \code{new}, that provides the needed type casting (notice
  that \code{Self} stands in here for the implementing type). The
  conformance of the \code{i32} and \code{f64} intrinsic types to the
  \code{INumeric} trait is then acknowledged via \code{impl} blocks,
  that furthermore implement any of the still outstanding
  functionality of this trait for these two types.
\item
  Where necessary, use of the \code{Copy} trait is also made, to
  work around Rust's default move semantics.
\item
  To help make all of the source code dependencies explicit,
  our Rust version employs modules, and \code{use} statements to import
  the required functionality.
\item
  Rust's default structure constructors exhibit the same restrictions
  as Fortran's. That is, they are unable to initialize from an
  external scope, structure components that are private to their
  module. As in Fortran, use of user-defined constructors must be made
  instead (cf. the \code{new} functions that are defined in separate
  \code{impl} blocks for the ADTs \code{PairwiseSum} and
  \code{Averager}).
\item
  To declare run-time polymorphic variables, one has to put so-called
  ``trait objects'' into ``Boxes'', i.e. to declare smart pointers of
  them, for dynamic instantiation and heap memory allocation (this is
  the Rust equivalent to using \code{allocatable} polymorphic objects
  in Fortran).
\end{itemize}

\lstinputlisting[language=Rust,style=boxed,label={lst:OORust},caption={Encapsulated Rust version of the array averaging example.}]{Code/Rust/mixed_poly/src/main.rs}

The Rust program version is somewhat longer than the corresponding Go
version, because user-defined constructors had to be provided, to
implement the aforementioned custom type conversion functionality and
to initialize module-hosted (opaque) abstract data types, and because
dependencies from external libraries, but also from modules of the user's
own crate, had to be imported into the \code{main} function (as it would
be necessary in realistic situations). The \code{main} function's
logic could also not be expressed as concisely as in the Go version,
because the various trait objects required (manual) ``boxing'' for their
instantiation, and because Rust's default move semantics had to be
worked around.

The most important difference between the two languages, though, is
that Rust uses traits (i.e. interfaces) as generics constraints whose
function signatures are always specified explicitly, whereas Go's are
typically specified implicitly (through type sets). Together with
Rust's capability (that Go lacks) to explicitly implement traits even
for language-intrinsic types, this allows Rust code to fully
(i.e. strictly) conform to OO programming's Open/Closed Principle. In
order to enable, for instance, the code of Listing~\ref{lst:OORust} to
accept also the \code{f32} type, one would simply need to add a
further module, that implements the \code{INumeric} trait for this new
intrinsic type. None of the pre-existing code would have to be
changed.

\section{Swift}
\label{sect:Swift}

Being a successor language to Objective-C, Swift differs slightly from
the languages considered so far in that it opted to retain
implementation inheritance for backwards compatibility to Objective-C,
whereas both Go and Rust do not support implementation inheritance
\emph{by design}. Swift therefore supports ``classical'' classes, but
it also allows one to bind methods to structures (which, in contrast
to classes, are value types in Swift).

Like Go and Rust, Swift (furthermore) supports a traits system
to implement both run-time and compile-time polymorphism through
polymorphic interfaces, that are called ``protocols'' in Swift. If the
Swift programmer chooses to ignore implementation inheritance and
classes, he can therefore very much program with structures and
protocols in Swift as he would with structures and interfaces/traits
in Go and Rust, respectively.

Given Swift's backwards compatible design, implementation of a
protocol (i.e. interface inheritance) is usually done as in classical
OO languages, i.e. within a structure's or a class's definition. A
colon (\code{:}) followed by one or more interface names must be
supplied for this purpose after the structure's or class's own
name. However, a very powerful facility for types to implement
protocols retroactively is also provided, through so-called
\code{extension}s, that work even if the types' source code is
inaccessible (because one is, e.g., working with a library in binary
form). In order to support strict conformance to the Open/Closed
Principle of OO programming, this same facility allows protocols to be
implemented also for language-intrinsic types. For instance, the
following little program, given by Listing~\ref{lst:extSwift}, prints
out ``\code{I am 4.9}''.
\lstinputlisting[language=Swift6,style=boxed,label={lst:extSwift},caption={Swift
    example of implementing a protocol for an intrinsic data
    type.}]{Code/Swift/printy.swift}

Swift generics support ``strong concepts'', and are thus fully
type-checked at compile time, and their capabilities are at least on
par with those of Go and Rust. In several aspects they are
actually superior. For instance, Swift allows function overloading to
be used together with generics \cite{Swift_Generics,Lyon}. Swift also
allows for parameterized \emph{methods}, instead of parameterized
protocols. The latter point has some interesting, positive
implications for the Swift programmer, that will be discussed in
detail below.

\subsection{Encapsulated version coded in Swift}

Listing~\ref{lst:OOSwift} gives an example of how the encapsulated
version of the array averaging test problem can be programmed in
Swift. See the following remarks, to understand this code.

\begin{itemize}
  \item
    By default, function and method calls in Swift need to make use
    of mandatory keyword arguments.
  \item
    Array slices are not arrays themselves. Hence, an explicit
    conversion of such slices via an \code{Array()} constructor is
    required to use them as arrays.
  \item
    Like Rust, Swift uses angled brackets to indicate generic
    parameter lists. Type constraints are formulated within these
    lists by supplying a protocol name after a generic type parameter
    (separated by a colon).
  \item
    Similar to Rust, Swift provides a \code{Numeric} protocol (that is
    defined in its standard library) for use as a generics constraint
    for numeric types, which however does \emph{not} include the
    division operation!
  \item
    It is easy to extend this protocol to support also the division
    operator, similar to the way we've extended traits in the Rust
    code example. However, the following code goes a step further than
    that, and foregoes any dependence on library functionality
    whatsoever, by defining a custom \code{INumeric} protocol that
    prescribes the interfaces of all the required operators and type
    initializers (i.e. constructors) explicitly.
  \item
    The present Swift code makes use of the language's default,
    built-in, initializers for the intrinsic types and the
    \code{SimpleSum} \code{struct} that it employs, and user-defined
    initializers for all the \code{struct}s that need to initialize
    \code{private} field variables.
  \item    
    Type conversion into a generic type, \code{T}, is effected in
    Swift by calling an appropriate initiali\-zer of this type. The
    call syntax is equivalent to that of Go's generic casts, but is a
    bit peculiar in that, e.g., Go's \code{T(0)} is written as
    \code{T(exactly:0)!} in Swift (making use of both the [default]
    initializer's mandatory keyword, \code{exactly}, and the \code{!}
    operator to unwrap the returned optional type). Notice, how the
    initializer's signature needs to be prescribed in protocol
    \code{INumeric}, in order to be able to use this functionality
    with some conforming type \code{T}.
  \item
    Swift's \code{Int32} and \code{Float64} intrinsic types already
    implement all of protocol \code{INumeric}'s functionality by
    default. It therefore suffices to simply acknowledge this fact
    through empty \code{extension} statements for these two types.
\end{itemize}

\newpage

\lstinputlisting[language=Swift6,style=boxed,label={lst:OOSwift},caption={Encapsulated Swift version of the array averaging example.}]{Code/Swift/mixed.swift}

Even a casual glance at the Swift version will show that the Swift
code is the easiest to read and understand among the generic
object-oriented implementations that were presented in this
chapter. This is largely the result of Swift supporting generic
methods, and hence not requiring the programmer to parameterize and
instantiate any generic interfaces (protocols), in contrast to both Go
and Rust. The consequences are
\begin{itemize}
\item
that method genericity for an ADT's objects can be expressed using
only a single, as opposed to multiple protocols,
\item
that therefore merely a \emph{single} object instance of that same
protocol is required, to be able to operate on many different
language-intrinsic data types, and
\item
that this also (largely) \emph{obviates the need for manual
instantiations of generics in Swift} (because generic
functions/methods are easier to instantiate automatically by the
compiler, as it can almost always infer the required types by checking
the regular arguments that are passed to a function/method)!
\end{itemize}

As an example, consider the object \code{av} in the above Swift code
that contains the functionality for array averaging. This object
supports two different levels of polymorphism: Firstly, given that it
is an instance of the \code{IAverager} protocol, it can be
polymorphically assigned different averaging algorithms (see the
\code{switch} statement). Secondly, because it contains an
\code{average} method that is generic, it can be used on data of
different intrinsic types, like \code{Int32} and \code{Float64} here.

Notice that the \code{main} function in the Swift code needs to
declare merely a \emph{single} such object variable of
\code{IAverager} type, to make use of all these capabilities. This is
a direct consequence of there being only a single
(i.e. unparameterized) version of the \code{IAverager} protocol, and
of parameterizing the protocol's method signatures by generic types
rather than the protocol itself.

Contrast this with Go's and Rust's model, where not only separate
objects of \code{IAverager} type are required for \emph{every}
different intrinsic data type that the programmer wishes to use these
objects with. But where also \emph{manual} instantiations of
corresponding versions of the generically parameterized
\code{IAverager} interface/trait are required from the programmer, for
declaring these objects. Swift's generics model gets rid of all of
that complexity, and therefore vastly simplifies client code. We
consider this a very significant advantage of the generics approach
that is taken in Swift vs. that of Go and Rust.

\section{Conclusions}

The use of run-time polymorphism by means of (polymorphic) interfaces
is rather similar in all the languages that were considered here. The
most significant difference in this respect is that Go has stricter
limitations than the other languages regarding code ownership, when it
comes to retroactively implementing interfaces for existing
types. Whereas Rust (with some minor restrictions), and Swift allow
the implementation of an interface by some type to be accomplished
effectively without regard to the type's definition site. Rust and
Swift thereby overcome Haveraaen et al.'s critique
\cite{Haveraaen_et_al_19} of Java regarding this point. In fact, it is
\emph{interface inheritance} which makes the uniform polymorphic
treatment of both intrinsic and user-defined types possible in the
first place in Rust and Swift, that Haveraaen et al. seem to also
(rightly) demand. All the considered languages are also quite similar
in that they support fully type checked generics via the mechanism of
interfaces. In the following, we will thus focus on summarizing the
most significant differences in these languages' generics features.

\subsection{Go}

Go's basic model to implement generics allows structures, interfaces,
and ordinary functions, but not methods, to be given their own generic
type parameters. The lack of true generic methods makes some
duplication of instantiation code in clients
unavoidable. Nevertheless, generic Go code is quite easy to read and
to understand. Go features built-in, easy to use support for
conversion to generic types. Yet, where Go truly differs from both
Rust and Swift are the unique, and extremely useful, implicit
mechanisms for conformance to interfaces that it supports, namely
structural subtyping, and the brilliant new notion of formulating
interfaces in terms of type sets, to which the member types of these
sets conform by definition.

The latter idea, along with the corresponding syntax to support it,
enables the Go programmer to formulate generics constraints very
naturally and concisely, without having to explicitly implement
interfaces for this purpose. This is what makes the use of generics in
Go pleasant. It is, moreover, essential for supporting concise generic
procedural and functional programming. While type sets retain their
advantages also in generic object-oriented programming, their
disadvantage in this setting is that they allow for only partial, but
not full, conformance to object-orientation's Open/Closed Principle.

\subsection{Rust}

Rust's basic model for generics is similar to Go's in that it allows
for parameterization of structures, interfaces, and ordinary
functions, but not necessarily methods. Hence, what has been said
above for Go in this respect holds also for Rust. Rust has,
unfortunately, some quirks which render its use for the management of
all types of dependencies through polymorphism somewhat sub-optimal
when compared to the other languages considered here. The language is
unpleasant to use, because of its ``borrow checker'', its employment
of move semantics by default, its \emph{excessive} obsession with type
safety, and its overall C++-like philosophy to copiously rely on
external dependencies, even for the most basic tasks.

Because of the latter two points, the Rust version of our test case is
marred by dependencies on external libraries, which is quite
contrarian to the purpose of programming in a polymorphic fashion,
namely to avoid rigid dependencies. Even with the functionality
provided by these external dependencies, casts to generic types within
generic routines weren't outright possible, and had to be achieved,
instead, through some work on the programmer's side. The points we
like most about the language are its idea to decouple trait
(i.e. interface) implementations from a \code{struct}'s definition
through \code{impl} blocks that work with both user-defined and
intrinsic types, the full conformance to the Open/Closed Principle
that this enables, and the complete control over the use of dynamic
vs. static method dispatch (via trait objects and generics,
respectively) that Rust affords the programmer. These are the features
of Rust that, in our opinion, Fortran should borrow in some form.

\subsection{Swift}

Swift's basic model of implementing generics by allowing parameterized
structures, functions, and methods (but not parameterized interfaces)
is both the easiest to read, and the easiest to use from a
programmer's perspective. In this model, if a programmer knows how to
write generic functions, his knowledge automatically translates into
coding generic methods. Swift's generics design supports casts to
generic types, regardless of whether these types are user- or
language-defined. Moreover, the Swift compiler is able to instantiate
generics largely automatically, through type inference of the regular
arguments that are passed to functions, methods, and (structure or
class) constructors. In contrast to the other languages, in Swift, the
user almost never has to bother with instantiating any generics.

Like Rust, Swift enables explicit and retroactive implementation of
interfaces for both user-defined and intrinsic types, and the full
conformance to the Open/Closed Principle of OOP that this affords
one. Unlike Rust and Go, Swift offers generics that are interoperable
with both class inheritance and ad hoc polymorphism (i.e. function
overloading), which are two features that are also an integral part of
Fortran. Out of all the considered modern languages, Swift therefore
shares the largest similarities with Fortran. Moreover, there is
notable documentation available
\cite{Swift_Generics,Swift_Generics_Book} on the model with which
Swift's generics are implemented in the Swift compiler. Finally, and
very importantly, with this implementation model, compilation times
scale only with the amount of generic code \emph{written}, rather than
the amount of code \emph{instantiated} \cite{Swift_Generics}. This is
in stark contrast to templated approaches (as used e.g. in C++).

For all these reasons, we consider Swift's generics to be the by far
most attractive model to base Fortran's generics capabilities
on. The fact that Swift is a language that does not put emphasis on
numerics, and whose present standard library therefore does not
provide a truly useful \code{Numeric} protocol/interface, is of
absolutely \emph{no} consequence for adopting Swift's generics design
as a baseline for Fortran. We believe, though, that this baseline
design would benefit substantially from being supplemented with Go's
implicit mechanisms for interface conformance.

Especially for properly supporting generic procedural and functional
programming in Fortran, i.e. for making them \emph{sufficiently
concise}, Go-like type sets should be added. These would also be
useful in generic object-oriented programming, even though Swift's
design already comes with good support for the latter, right out of
the box. Its single minor disadvantage in this respect, namely the
need to always provide (possibly empty) explicit \code{extension}
blocks to implement a new interface, even if the involved types already
command over all of the functionality that is prescribed by that
interface, could be overcome by allowing for Go-like structural, in
addition to nominal, subtyping. A conclusion that seems to have been
arrived at also in the recent Mojo language \cite{MojoRef}. See
Sects.~\ref{sect:ocp_conformance} and \ref{sect:structural_subtyping}
for some further discussion of this point.


\chapter{Fortran extensions I: Traits for types}
\label{chapt:traits}

The present and the next chapter, describe a number of simple
extensions to Fortran, that we consider essential for enabling
dependency management through polymorphism at a level of functionality
that is on par with modern languages like Swift, Rust, Go, Carbon, or
Mojo. The present chapter adds general subtyping capabilities to
Fortran, while the next chapter aims at providing specific support for
generics. The extensions that are related to subtyping concern
abstract interfaces, derived types, and the \code{class} specifier for
variable declarations. They also encompass an important, new, Fortran
feature: the \code{implements} statement.

\section{Traits (named abstract interfaces) }
\label{sect:traits}

The most essential of all the following extensions is the capability
to define named abstract interfaces, or traits (i.e. named collections
of procedure signatures), in order to suitably constrain (and hence to
type-check) the declarations of polymorphic variables. Traits are the
crucial feature that is required to uniformly and properly
express both run-time and compile-time polymorphism (i.e. modern-day
OO and generic programming, respectively) in the language, and to
thereby enable a uniform management of dependencies on both
user-defined \emph{and} language-intrinsic types.

\subsection{Definition}
\label{sect:interface_defs}

Fortran already allows the programmer to define unnamed abstract
interfaces. But to use these as traits, named versions of them are
required. Moreover, and in order to support all of the functionality
that is discussed in the next sections, these interfaces must admit
signatures of not only ordinary type-bound procedures, but also
initializers (i.e. constructors), and operators (including
assignments). The following example defines three such traits,
\code{ICastable}, \code{ICalculable}, and \code{IPrintable}, that are
intended as abstract blueprints for actual type-bound implementations
of, respectively, an initializer, \code{init}, a function,
\code{saxpy}, and a subroutine, \code{output}:
\begin{lstlisting}[language=LFortran,style=boxed]
  abstract interface :: ICastable
     function init(n)
        integer, intent(in) :: n
     end function init
  end interface ICastable

  abstract interface :: ICalculable
     function saxpy(a,x,y) result(res)
        real, intent(in) :: a, x(:), y(:)
        real             :: res(:)
     end function saxpy
  end interface ICalculable

  abstract interface :: IPrintable
     subroutine output()
     end subroutine output
  end interface IPrintable
\end{lstlisting}
Examples of traits with signatures of type-bound operators are given
in Sects.~\ref{sect:tats}, \ref{sect:ocp_conformance}, and
\ref{sect:overloading}. Notice, how initializers within traits are
declared as \emph{special} functions, that have a reserved name,
\code{init}, and for which no return type is specified. Because the
latter is considered to be already fully determined by the initialized
type. This is equivalent to how initializers are declared
in Swift protocols.

It should also be pointed out that traits contain the signatures of
\emph{messages}, which in OO and generic programming may be sent to
different receivers. A well-designed traits facility should therefore
\emph{not} require such message signatures to contain passed-object
dummy arguments, or their types, i.e. any details concerning the
receivers. Because in order to be sendable to different receivers, a
message must not know anything about its receiver. This is clearly
exhibited by the present examples, and also the Go and Swift
examples\footnote{Notice, especially, that despite the fact that Go
(like Fortran) uses explicitly passed receiver objects, these appear
only in the actual \emph{implementations} of methods, and even there
they are clearly \emph{syntactically separated} from the latter's
interfaces.} of Listings~\ref{lst:OOGo} and \ref{lst:OOSwift}. But it
is violated in present Fortran practice by \code{deferred} type-bound
procedures. We will elaborate further on this in
Sect.~\ref{sect:abstract_types}. There, we will also show how to fix
this problem, while achieving interoperability of the new traits
facility with the inheritance feature that is already available in the
present language.

\subsection{Overloading}
\label{sect:overloaded_signatures}

In the examples that were considered so far, traits were shown to
contain uniquely named message signatures. But since Fortran supports
ad hoc polymorphism through ``\code{generic}'' overloading, traits
must also admit \emph{overloaded} versions of initializer, method,
operator, and assignment signatures -- that share a generic name, but
differ in their arguments lists. The following trait,
\code{IConstructable}, illustrates this for a type-bound initializer,
by overloading the reserved name \code{init} with two such signatures:
\begin{lstlisting}[language=LFortran,style=boxed]
  abstract interface :: IConstructable
     function init(n)
        integer, intent(in) :: n
     end function init
     function init(a)
        real, intent(in) :: a
     end function init
  end interface IConstructable
\end{lstlisting}
Traits for all the other cases can be formulated analogously --
through overloaded use of a method name, or the reserved identifiers
\code{operator(\emph{op})}, and \code{assignment(=)}, respectively
(with \code{\emph{op}} as per \cite{Fortran_standard}). An example of
an overloaded multiplication operator signature is given in
Sect.~\ref{sect:overloading}.

\subsection{Extends attribute}
\label{sect:extends_spec}

Abstract interface definitions must allow the programmer to define new
traits that inherit procedure signatures from \emph{multiple} simpler
traits (multiple interface inheritance). In the following example, the
trait \code{IAdmissible} inherits the procedure signatures that are
contained in both the \code{ICastable} and \code{IPrintable} traits of
Sect.~\ref{sect:interface_defs}, making \code{IAdmissible} at the same
time a \emph{subtype} of both these simpler traits:
\begin{lstlisting}[language=LFortran,style=boxed]
  abstract interface, extends(ICastable + IPrintable) :: IAdmissible
  end interface IAdmissible
\end{lstlisting}
That is, objects that implement (or adopt) the \code{IAdmissible}
trait (i.e. conform to it), can also be used in settings that require
conformance to either the \code{ICastable}, or \code{IPrintable}
traits.

The next example finally shows an extended version of the
\code{IAdmissible} trait, that not only inherits the aforementioned
procedure signatures, but also adds the signature of a further method,
\code{input}, to them:
\begin{lstlisting}[language=LFortran,style=boxed]
  abstract interface, extends(ICastable + IPrintable) :: IAdmissible
     subroutine input(filename)
        character(*), intent(in) :: filename
     end subroutine input
  end interface IAdmissible
\end{lstlisting}

\section{Implements statement}
\label{sect:implements_stmt}

The language must allow not only for traits to conform to other traits
(cf. Sect.~\ref{sect:extends_spec}), but also for both
language-intrinsic and user-defined types to do the same. That is, it
must be possible for these types to acknowledge their conformance to a
trait, if they already command over implementations of all its
functionality, or to provide any still outstanding implementations
that are required for such conformance. Moreover, this must be
possible even retroactively, i.e. regardless of (and without having to
touch) any original type definition site\footnote{Exempting only the
case of abstract derived types, as it is discussed below.}. Otherwise,
wrapper types would, in general, need to be written, once an already
defined type would need to implement some new trait (e.g. in cases
where the original type definition is inaccessible). This also means
that the provision of user-defined functionality needs to be allowed
even for \emph{language-intrinsic} types\footnote{With some
restrictions. See Sect.~\ref{sect:implement_intrinsic_type}.}. The
\code{implements} statement, that is described in this section,
provides these capabilities.

\subsection{Overview}

The \code{implements} statement is modeled after the
``\code{extension}'' feature of Swift, to enable retroactive
implementation of new methods, initializers, operators, and especially
traits for types, in order to \emph{dynamically} change a subtyping
(i.e. interface inheritance) hierarchy, and to thus achieve utmost code
flexibility. Swift's \code{extension} blocks fulfill essentially the
same purpose as Rust's \code{impl} blocks. They have been somewhat
simplified here, and adjusted to Fortran's idiosyncracies and syntax,
that binds procedures to types through declaration blocks, rather than
by including the actual implementations themselves into such a block
(the implementations need to be supplied as module procedures, as it
is usual in Fortran).

The syntax of the feature is an extended subset of that for the
\code{contains} sections of derived type definitions. That is,
\code{implements} statements make use of type-bound procedure
declarations. These employ the already well-known attributes
\code{public}, \code{private}, \code{pass[(arg-name)]}, \code{nopass},
and \code{non\_overridable}, along with the new attribute
\code{static}. Some additional syntax for these declarations is
provided, to enable direct overloading of method names, and to thus
make it less verbose than through the use of \code{generic} type-bound
procedure declarations (as the Fortran standard calls them). However,
the latter are supported as well. Furthermore, a new type of
\code{initial} procedure declarations is available, for specifying
type-bound initializers (i.e. constructors).

The main difference to derived type definitions is that the
\code{implements} statement does not accept declarations of
\code{deferred} type-bound procedures (which we propose to retire
partly or entirely, see Sect.~\ref{sect:abstract_types}), and that it
cannot be used with \code{abstract} derived types. If interoperability
with \code{abstract} types is required, the later to be discussed
\code{implements} derived type attribute (cf.
Sect.~\ref{sect:derived_types}) can be used instead. As a final
disclaimer, notice that the \code{implements} statement has \emph{no}
relation to subclassing, i.e. one derived type being extended into
another through (rigid) implementation inheritance. Rather, this is a
feature that adds new capabilities to a single, \emph{given}, type.

\subsection{Binding functionality to a type}
\label{sect:adding_methods}

The most basic use of the \code{implements} statement is to
(retroactively) bind procedures of varying functionality to a
type. The following example shows how to bind the names of an
overloaded, user-provided, initializer, and an ordinary method to a
derived type with name \code{MyType}, and how to provide their actual
implementations as module procedures:
\begin{lstlisting}[language=LFortran,style=boxed]
module basic
   ...
   type :: MyType
      private
      real :: a
   end MyType

   implements :: MyType
      initial :: init => init_by_int, init_by_real
      procedure, pass :: output
   end implements MyType
   
contains

   function init_by_int(n) result(res)
      integer, intent(in) :: n
      type(MyType)        :: res
      res%a = real(n)
   end function init_by_int

   function init_by_real(a) result(res)
      real, intent(in) :: a
      type(MyType)     :: res
      res%a = a
   end function init_by_real

   subroutine output(self)
      class(MyType), intent(in) :: self
      write(*,*) "I am ", self%a
   end subroutine output

end module basic      
\end{lstlisting}

Notice the use of the new declaration of \code{initial} type, that
instructs the compiler to overload the implementing type's structure
constructor with, in this case, multiple type-bound initializer
implementations of the (reserved) generic name \code{init}. Notice,
also, that the return type of a module function that actually
implements an initializer is always the concrete type that it
initializes.

The above example also demonstrates how an ordinary method of name
\code{output} can be bound to \code{MyType}, in quite the same manner
as this is accomplished in the present language. That is, by declaring
the passed-object dummy argument, \code{self}, with the \code{class}
declaration specifier (as it is required for my \code{MyType} to be
usable as a base type for implementation inheritance).

\subsection{Implementing traits}
\label{sect:implementing_traits}

\subsubsection{Retroactive implementation}

Assume now, that the purpose of binding the previous procedures to
\code{MyType} was to actually make this type compatible with settings
where conformance to the \code{IPrintable} and \code{IConstructable}
traits of, respectively, Sects.~\ref{sect:interface_defs} and
\ref{sect:overloaded_signatures} is required.  So far, we have
provided both the bindings of the required initializers and method, as
well as their implementations -- making sure that the signatures of
the latter match those that are contained in the \code{IConstructable}
and \code{IPrintable} traits, by ignoring any passed-object arguments
(which a compiler will simply skip, in the present design, when
checking for trait, i.e. interface, conformance of an implementation).

However, we haven't made \code{MyType} pluggable yet into code that is
written in terms of these traits. To fix this, we can simply
acknowledge (even from a different module, as in the following
example) that \code{MyType} already has all of the required
functionality to implement these traits:
\begin{lstlisting}[language=LFortran,style=boxed]
module enhanced
   ...  
   use basic, only: MyType

   implements (IConstructable + IPrintable) :: MyType
   end implements MyType

end module enhanced
\end{lstlisting}

It is crucial for flexibility, that the subtyping (i.e. interface
inheritance) mechanism, that the \code{implements} statement provides,
allow for a type to implement \emph{multiple} different traits --
as it is demonstrated in this example.

\subsubsection{Collective implementation}

The last code example has shown how traits can be implemented
after the procedure implementations, that they require, were already
bound to some type. Of course, it is also possible to do all of this
at one fell swoop, as in the following alternative version of the
module \code{basic}, whose original version was given in
Sect.~\ref{sect:adding_methods}:
\begin{lstlisting}[language=LFortran,style=boxed]
module basic
   ...
   type :: MyType
      private
      real :: a
   end MyType

   implements (IConstructable + IPrintable) :: MyType
      initial :: init => init_by_int, init_by_real
      procedure, pass :: output
   end implements MyType

contains
...
end module basic      
\end{lstlisting}
To avoid needless repetition, we have omitted here the implementation
of the actual procedures, that would be done exactly as it was shown in
Sect.~\ref{sect:adding_methods}.

\subsubsection{Split implementation}

We could have also employed two separate \code{implements} statements,
in order to implement one trait at a time, and achieve the same
effect:
\begin{lstlisting}[language=LFortran,style=boxed]
module basic
   ...
   type :: MyType
      private
      real :: a
   end MyType

   implements IConstructable :: MyType
      initial :: init => init_by_int, init_by_real
   end implements MyType

   implements IPrintable :: MyType
      procedure, pass :: output
   end implements MyType

contains
   ...   
end module basic      
\end{lstlisting}
Here we have skipped again, for brevity, the actual implementations.
Such a splitting of \code{implements} statements can be useful to
improve code readability, as it makes the association between the
traits and the actual procedures, that are to be implemented for
any one of them, immediately obvious. These two statements (together
with the actual implementations) could then have been distributed
even among different modules and files. Notice, also, how parentheses
around traits lists in \code{implements} statements are optional,
but not required.

\subsection{Implementing traits for intrinsic types}
\label{sect:implement_intrinsic_type}

The \code{implements} statement can be used to provide new
functionality also for types that are \emph{intrinsic} to the language
-- in quite the same fashion as it was already demonstrated for
derived types. However, the present language features some
restrictions in this context, that we deem essential to retain. In
particular, present Fortran doesn't allow one to overload, i.e. to
change, the implementations of the intrinsic operators that the
language defines for intrinsic types. Which is what makes numeric
Fortran code \emph{predictable}. Any present restrictions that serve
this latter purpose should therefore continue to be honored.

The following listing, which shows how to code the Swift example of
Listing~\ref{lst:extSwift}, is a case that is unaffected by these
considerations. It implements the \code{IPrintable} trait, with its
single method \code{output}, for Fortran's \code{real(real64)} type,
to perform printouts for variables of this type:

\lstinputlisting[language=LFortran,style=boxed]{Code/Fortran/printy.f90}

Notice, that once an \code{implements} statement has been used to
augment the functionality of an existing (intrinsic or derived) type
(like the \code{real(real64)} type in the above example), then this
new functionality will be available on \emph{all} instances of that
type, even if they were created before this augmentation was
defined. As it is the case in the Swift language \cite{SwiftLangRef},
this prevents the occurrence of any ambiguities regarding the
available functionality of such type instances. For the same reason,
it is sufficient to import into client code (as usual) either a named
constant corresponding to an intrinsic type's kind parameter (like the
\code{real64} constant in the above \code{printy} example program), or
a derived type's (original) definition, in order to make use of the
thus augmented functionality.

\section{Implements derived type attribute}
\label{sect:derived_types}

For reasons of both regularity in the language, and interoperability
with Fortran's legacy (i.e. present) OO model, it should be possible
to implement traits also directly from within derived type
definitions. This can be accomplished by allowing an \code{implements}
\emph{attribute} within such definitions, that -- in contrast to the
\code{implements} statement -- features also interoperability with
\code{abstract} derived types, and their extensions by implementation
inheritance.

By its very nature of being bound to derived type definitions, the
former attribute, though, necessarily lacks the latter statement's
retroactive implementation capabilities, that are important for
exploiting the full possibilities of the traits-based OO programming
model. The latter model is a much more flexible, complete, modern-day
alternative to both \code{abstract} types and type extension
(i.e. implementation inheritance). Hence, our recommendation is to use
the interoperability features, that are described in the following
Sects.~\ref{sect:extended_types} and \ref{sect:abstract_types}, mainly
as migration tools (for modernizing legacy applications incrementally,
through refactoring), and to otherwise avoid the use of both
\code{abstract} types and type extension in new programs.

\subsection{Use with the sealed attribute}
\label{sect:sealed_types}

The following code shows how the ``Collective implementation'' example
of Sect.~\ref{sect:implementing_traits}, that was written there in
terms of an \code{implements} statement, can be reformulated to use an
\code{implements} derived type attribute:
\begin{lstlisting}[language=LFortran,style=boxed]
module basic
   ...
   type, sealed, implements(IConstructable + IPrintable) :: MyType
      private
      real :: a
   contains
      initial :: init => init_by_int, init_by_real
      procedure, pass :: output
   end implements MyType
   
contains

   function init_by_int(n) result(res)
      integer, intent(in) :: n
      type(MyType)        :: res
      res%a = real(n)
   end function init_by_int

   function init_by_real(a) result(res)
      real, intent(in) :: a
      type(MyType)     :: res
      res%a = a
   end function init_by_real

   subroutine output(self)
      type(MyType), intent(in) :: self
      write(*,*) "I am ", self%a
   end subroutine output

end module basic      
\end{lstlisting}

This example also demonstrates the use of a second, new, derived type
attribute, the \code{sealed} attribute. Derived types that are
\code{sealed} are inextensible by type extension, i.e. implementation
inheritance. Thus, there's also no need for the passed-object dummy
arguments of such types to be polymorphic, and hence for the
programmer to declare them with the \code{class} specifier. One can
use the \code{type} specifier, instead, as it is demonstrated by the
implementation of method \code{output} in the above example.

\subsection{Use with the extends attribute}
\label{sect:extended_types}

The previous Sect.~\ref{sect:sealed_types} has illustrated how the
\code{implements} derived type attribute would be typically used in
modern code (that avoids the use of implementation inheritance, or
subclassing). However, the multiple interface inheritance (or
subtyping) features, that are provided by the \code{implements}
derived type attribute\footnote{And, with some restrictions, also the
\code{implements} statement.}, can actually be combined with the type
extension capabilities which are already present in the language.

In the following example, a \code{Parent} type is defined, that
implements a \code{method1}. The implementation of the latter is then
inherited by a \code{Child} type, that, in turn, implements an
own \code{method2}. In this way, the \code{Child} type now commands
over implementations of both \code{method1}, and \code{method2}, as it
is required for it to conform to both the \code{IParent} and
\code{IChild} traits, respectively, that it adopts. Which
consist of the signatures of these methods.

\lstinputlisting[linerange={1-52},language=LFortran,style=boxed]{Code/Fortran/Interop/extends_parent.f90}

In cases like the present one, where the \code{extends} and
\code{implements} derived type attributes are used in combination,
\code{extends} shall always precede \code{implements}. Since the
latter attribute allows for the inheritance of \emph{multiple}
interfaces/traits, as it is demonstrated in this example, this also
fixes present Fortran's single inheritance limitations, \emph{without}
introducing the potential ambiguities that multiple inheritance of
implementation would cause (which are also known as ``The Diamond
Problem'').

\subsection{Use with the abstract attribute}
\label{sect:abstract_types}

The two previous examples of the \code{implements} derived type
attribute, that were presented in Sects.~\ref{sect:sealed_types} and
\ref{sect:extended_types}, can, in fact, be coded equally well using
\code{implements} statements. Yet, the \code{implements} attribute
provides one capability that the \code{implements} statement lacks,
namely implementation of traits even if the implementing derived type
is \code{abstract}.

It must be noted, in this context, that the \code{implements}
attribute provides a new, far more general, facility for requiring
derived types to provide implementations of abstract methods, than the
present language's \emph{flawed} (non-generalizable) mechanism of
declaring methods with the \code{deferred} attribute. The latter
feature's way of prescribing abstract method signatures differs from
the traits based \code{implements} mechanisms that are proposed here,
in that it generally requires these signatures to contain entirely
\emph{superfluous} passed-object dummy arguments, which unnecessarily
and wrongly \emph{intermix} the receiver of a message (i.e. the
passed-object), with the interface of the message itself.

This is a fundamental design flaw in the present language that
requires correction, and couldn't be simply carried over to the design
of the traits based facilities, because it would have compromised all
the new features that are based upon traits. In order to avoid having
(in the long run) two subtly different ways of expressing abstract
method signatures in the language, we propose to first make the
specification of passed-object dummy arguments, in abstract interfaces
of \code{deferred} methods, optional rather than mandatory, and to
subsequently declare obsolescent such mandatory
specification. Alternatively, Fortran's \code{deferred} type-bound
procedure declarations could be retired in their entirety, in favor of
using traits, as it is demonstrated in the following example:

\lstinputlisting[linerange={1-52},language=LFortran,style=boxed]{Code/Fortran/Interop/abstract_new.f90}

Here, the \code{abstract} type \code{Parent} provides an
implementation of a \code{method1}, but it also obliges any type that
derives from it to implement the abstract \code{method2}. In present
Fortran, this would be expressed through a \code{deferred} type-bound
procedure declaration for \code{method2} within \code{Parent}, along
with the provision of an unnamed abstract interface. Whereas in the
above example this is formulated in the alternative way of using a
trait: \code{Parent} is made to \code{implement} the \code{IDeferred}
trait, that contains the abstract signature of \code{method2}. But
since \code{Parent} is declared, at the same time, with the
\code{abstract} attribute, it can pass this obligation to its
children. Hence, the \code{Child} type, that \code{extends(Parent)},
is now expected to provide an actual implementation of this method.

More generally, a type that is declared \code{abstract}, is allowed to
provide partial or no implementations of the traits that it, or its
ancestors, adopt. Any non-abstract type that \code{extends} such an
\code{abstract} type through type extension must, however, provide
full implementations. This is equivalent to how interfaces work in
conjunction with \code{abstract} classes in the Java language
\cite{JavaTutorial}.

\section{Trait objects (run-time polymorphic variables)}
\label{sect:trait_objects}

The main purpose of named abstract interfaces/traits is to allow the
programmer to declare (and thereby constrain) polymorphic variables in
terms of them. This can happen either directly, by traits functioning
as types in run-time polymorphism (as it is demonstrated in this
section), or indirectly, by them acting as constraints on generic type
parameters in compile-time polymorphism (see, e.g.,
Sect.~\ref{sect:generic_interfaces}).

\subsection{Class specifier using a single trait}

In order to use traits to declare run-time polymorphic objects through
subtyping, Fortran's \code{class} specifier for polymorphic variable
declarations needs to be enhanced to accept traits; like in the
declarations of the following two variables (that make use of the
\code{IPrintable} trait of Sect.~\ref{sect:interface_defs})
\begin{lstlisting}[language=LFortran,style=boxed]
  class(IPrintable), allocatable :: printer
  class(IPrintable), pointer     :: printerptr
\end{lstlisting}
or the following declaration of a procedure argument:
\begin{lstlisting}[language=LFortran,style=boxed]
  class(IPrintable), intent(in) :: printer
\end{lstlisting}
The semantics here are that whenever a trait appears within the
\code{class} specifier of an object's declaration, then all the
\code{public} methods of that object whose signatures are prescribed
by the adopted trait (like \code{IPrintable} in the above examples),
will make use of dynamic binding. That is, their calls will be
resolved by the run-time system of the language (e.g. through a
virtual method table). See also Sect.~\ref{sect:restrictions} for
further information on the \code{class} specifier when used with
traits.

In accordance with how objects that make use of run-time polymorphism
through subclassing (i.e. implementation inheritance) are declared in
the present Fortran standard, also ``trait objects'' (like
\code{printer}, and \code{printerptr} in the examples above) must
either be declared using the \code{allocatable}, or the \code{pointer}
attribute, or they must be arguments of a procedure. The proposed
extensions are therefore backwards compatible with the functionality
that is already available in the present language.

\subsection{Class specifier using trait combinations}
\label{sect:trait_combinations}

The \code{IAdmissible} trait of Sect.~\ref{sect:extends_spec}
derives from the \code{ICastable} and \code{IPrintable} traits of
Sect.~\ref{sect:interface_defs}. An object that requires the combined
functionality of both these latter traits could thus be declared
in terms of the \code{IAdmissible} trait as follows:
\begin{lstlisting}[language=LFortran,style=boxed]
  class(IAdmissible), allocatable :: obj
\end{lstlisting}
It happens often, though, that one needs to declare objects that
conform to multiple traits, but where one would like to avoid having
to code some (otherwise unneeded) intermediary trait, that derives
from these. In such cases, it should be possible to express an
object's declaration more directly -- by providing a traits
combination to the class specifier. As in the following example
\begin{lstlisting}[language=LFortran,style=boxed]
  class(ICastable + IPrintable), allocatable :: obj
\end{lstlisting}
in which \code{obj} again conforms to both the \code{ICastable}
and \code{IPrintable} traits.


\chapter{Fortran extensions II: Generics}

The new subtyping features that were discussed in the previous chapter
are required to uniformly express and support both run-time and
compile-time polymorphism in Fortran. We will now proceed with
describing further enhancements that are specifically needed in order
to support compile-time polymorphism, i.e. generics.

\section{Enhancements to traits}
\label{sect:interface_enhancements}

\subsection{Traits with generic procedure signatures} 
\label{sect:generic_interfaces}

Abstract interface definitions must be allowed to contain the
signatures of generically parameterized procedures, as it is the case
in the Swift language. Parameterizing the abstract interfaces
themselves (as in Go or Rust) is not as attractive from a user's
perspective (cf. Sect.~\ref{sect:Swift}). As an example, the following
code shows a trait that is called \code{ISum}, which contains a
signature that is intended for a generic type-bound function
(i.e. generic method) with name \code{sum}:
\begin{lstlisting}[language=LFortran,style=boxed]
  abstract interface :: ISum
     function sum{INumeric :: T}(x) result(s)
        type(T), intent(in) :: x(:)
        type(T)             :: s
     end function sum
  end interface ISum
\end{lstlisting}

The example illustrates the use of a generic type parameter, that is
simply called \code{T} here, in terms of which the regular function
arguments are declared. A significant difference of generic type
parameters, as compared to regular function arguments, is that the
former will be substituted by actual \emph{type} arguments at compile
time, in a process that is called instantiation.

A similarity is that, in the same way that regular function arguments
need to be constrained by a provided type, type parameters need to be
constrained by a provided meta-type. This (meta-type) constraint must
either be the name of a single trait (like \code{INumeric} in the
present example), or a traits combination that is expressed in terms
of the \code{+} operator\footnote{For usage examples of traits
combinations in run-time and compile-time polymorphism, see
Sects.~\ref{sect:trait_combinations} and \ref{sect:overloading},
respectively.}. If the constraint is omitted by the programmer, then
the compiler will infer the corresponding type parameter to be
constrained by the \code{IAnyType} (empty) trait of
Sect.~\ref{sect:type_sets}. The proposed Fortran generics thus support
``strong concepts'', and can be fully type-checked by a compiler.

Both, the type parameter and the constraint which precedes it, and is
separated from it by a double colon, are part of a generic type
parameters list that is enclosed in curly braces, and follows
immediately behind the procedure's name. Notice that the syntax that
is used here, which deviates slightly from how Fortran's regular
function arguments are declared, appears justified, as it reflects
that, despite some similarities, in type parameters one is dealing
with different entities.

%Notice that as a direct consequence of the ad hoc polymorphism of
%Sect.~\ref{sect:overloaded_signatures}, \emph{overloaded} generically
%parameterized procedure signatures, that make use of a common name,
%are also allowed to appear within a trait -- as long as they differ
%in either their regular arguments lists, or their generic type
%parameters lists.


\subsection{Traits of type sets}
\label{sect:type_sets}

To make Fortran's traits based generics facility easy to use, the
language should allow for generics constraints to be expressed in an
\emph{implicit} fashion, as abstract interfaces/traits that are
formulated in terms of type sets, as it is possible in the Go
language. This is particularly important for admitting the use of
selected sets of intrinsic types in generic code (and the multitude of
intrinsic procedures that Fortran supports for these types). It is
also essential for supporting concise generic procedural and
functional programming, where one might wish to avoid having to
explicitly implement interfaces and methods for types (which is,
arguably, an OO technique).

\subsubsection{Unions of types}

The following example shows the simplest form of such a type set. It
defines an \code{INumeric} trait, for use as a generics constraint
in the example of Sect.~\ref{sect:generic_interfaces}, in order to
admit for the type parameter, \code{T}, that was given there, only the
(32 bits wide) default \code{integer} intrinsic data type:
\begin{lstlisting}[language=LFortran,style=boxed]
  abstract interface :: INumeric
     integer
  end interface INumeric
\end{lstlisting}

The above example is actually a special case of specifying entire
\emph{unions} of member types as a type set. A type set consisting of
such a union of types is demonstrated in the following example
\begin{lstlisting}[language=LFortran,style=boxed]
  abstract interface :: INumeric
     integer | real(real64)
  end interface INumeric
\end{lstlisting}
that redefines the \code{INumeric} trait such as to admit either the
default 32 bit \code{integer}, or the 64 bit \code{real} type as a
generics constraint.

The semantics of such a type set construct are that it implicitly
defines a \emph{set of procedure signatures}, namely the signatures of
the intersecting (common) set of all the operations and intrinsic
procedures (also called methods in the following) that work with all
the member types of the type set. This can also be restated, by saying
that a type \code{T} \emph{implements} a trait consisting of such a
type set, if (and only if) it is a member type of this set. For
instance, the \code{integer} and \code{real(real64)} types implement
the \code{INumeric} trait (as it is given above) because they are
member types of its type set. In contrast, Fortran's various
\code{complex} types do not implement this trait, because they do not
belong to its set of member types. The validity of the latter
statement can be easily checked, by considering that the
\code{complex} types do not support, i.e. implement, the relational
operators \code{(<)} and \code{(>)}. Implementations of the latter are
required for conformance to this trait, because these operators
\emph{are} implemented by both the \code{integer} and
\code{real(real64)} member types.

\subsubsection{Assumed kind parameters}

Expanding on the previous example, an \code{INumeric} trait that
might be even more useful as a generics constraint, for a number of
numeric tasks, could be coded as follows:
\begin{lstlisting}[language=LFortran,style=boxed]
  abstract interface :: INumeric
     integer(*) | real(*) | complex(*)
  end interface INumeric
\end{lstlisting}
Notice how this makes use of both unions of types, and assumed
(i.e. wildcard) kind parameters for types, to include \emph{all}
\code{integer}, \code{real}, and \code{complex} types, that are
admitted by the language, in a single \code{abstract interface}
constraint.

The use of assumed kind parameters is here merely syntactic sugar
that allows one to avoid having to write out a type set for all
the possible kinds of a type. For instance, if the particular Fortran
implementation supports \code{real(real32)} and \code{real(real64)} as
its only \code{real} types, then \code{real(kind=*)}, or
\code{real(*)} for short, is understood to mean the type set
``\code{real(real32) | real(real64)}''. Notice, also, that the more
types are added to a trait in this fashion, the smaller the set
of intersecting methods will usually become.

\subsubsection{Empty trait}

In the limit of adding all possible types to a type set, there won't
be any common methods left that are implemented by all its types. This
results in the important case of the empty trait, that matches all
types (since any type has at least zero methods):
\begin{lstlisting}[language=LFortran,style=boxed]
  abstract interface :: IAnyType
  end interface IAnyType
\end{lstlisting}

\subsubsection{Inline notation}

For simple use cases, it should be optionally possible for the
programmer to employ a shorter notation for declaring type constraints
for generics, than having to separately define a trait of type
sets, like \code{INumeric} above, and to then use it as in
Sect.~\ref{sect:generic_interfaces}. The following modification of
trait \code{ISum}'s original declaration of
Sect.~\ref{sect:generic_interfaces}, provides such an example:
\begin{lstlisting}[language=LFortran,style=boxed]
  abstract interface :: ISum
     function sum{integer | real(real64) :: T}(x) result(s)
        type(T), intent(in) :: x(:)
        type(T)             :: s
     end function sum
  end interface ISum
\end{lstlisting}
The inline use of a type set, within the type parameters list in curly
braces, is an alternative notation for defining a type
set trait for use as a generics constraint for type \code{T}. In this
particular case, for admitting only the 32 bit \code{integer}, or 64
bit \code{real} type for \code{T}, as it was discussed above.

\subsection{Traits with associated (deferred) types}
\label{sect:tats}

In addition to supporting implicitly expressed generics constraints
trough type sets, the language must allow such constraints to be
formulated also through \emph{explicit} specification of the
signatures of ordinary type-bound procedures, initializers, or
operators in traits. The proper support of operator signatures, but
also of other generic functionality, requires the use of so-called
associated types within traits. Associated types (which are
also available in Rust and Swift) are essentially aliases. They are
employed within traits, in lieu of types whose actual value is not
known at the time a trait is formulated, but will be known by a
compiler once the programmer has actually implemented that trait for
some (concrete derived or intrinsic) data type.

A typical use case for associated types is when a trait needs to refer
to the implementing type itself. This use case is, in fact, so
frequent that the aforementioned languages provide a predefined
associated type, \code{Self}, for it. In Fortran (which is
case-insensitive), we propose to call this type \code{itself}. The
following version of an \code{INumeric} trait makes use of this
predefined type, in order to explictly declare the signatures of an
\code{operator(+)} for addition, and an \code{operator(/)} for
division, that together with the signature of an explicitly declared
initializer, \code{init}, are intended for use as a generics
constraint within the \code{ISum} trait of
Sect.~\ref{sect:generic_interfaces}:

\lstinputlisting[linerange={8-21},language=LFortran,style=boxed]{Code/Fortran/ocp.f90}
For a more comprehensive usage example, see
Sect.~\ref{sect:ocp_conformance}, where this trait is employed in the
framework of our standard test problem, to strictly conform to OOP's
Open/Closed Principle.

In general, associated types will have to be declared by the
programmer himself, using \code{deferred} type-definition statements,
as it is shown in the following example of the trait
\code{IAppendable}:
\lstinputlisting[linerange={5-11},language=LFortran,style=boxed]{Code/Fortran/vector.f90}
This trait requires any implementing type to provide a subroutine for
appending certain items (to the type). The type of these items is
unknown upon trait formulation, and is therefore declared using the
\code{deferred} (i.e. placeholder) type \code{Element}, that is left
for inference by the compiler. A worked out example that illustrates
the actual use of this trait is provided in
Sect.~\ref{sect:associated_types_usage}.

\subsection{Predefined traits}

The facilities that were described in the previous sections are
flexible enough to enable the user to easily construct generics
constraints himself, the way he needs them. Nevertheless, the language
should ideally also supply a collection of already predefined,
frequently used, generics constraints, in the form of traits that are
contained in a language-intrinsic module (that we'll tentatively call
\code{generics} here). A list of such predefined traits could include
\begin{itemize}
\item
  the empty trait \code{IAnyType} that admits any type (see
  Sect.~\ref{sect:type_sets}),
\item
  some predefined numeric traits allowing for different numeric
  operations, but also
\item
  some predefined traits to allow for the use of relational operators
  with different types.
\end{itemize}

Such traits could then be imported from user code through a \code{use}
statement, like in the following example, that assumes the existence of
a language defined trait \code{INumeric}:
\begin{lstlisting}[language=LFortran,style=boxed]
module user_code

   use, intrinsic :: generics, only: INumeric

   abstract interface :: ISum
      function sum{INumeric :: T}(x) result(s)
         type(T), intent(in) :: x(:)
         type(T)             :: s
      end function sum
   end interface ISum

end module user_code
\end{lstlisting}

\subsection{Present restrictions}
\label{sect:restrictions}

The previous sections have shown examples of four kinds of
traits, namely
\begin{itemize}
\item
  traits of type sets (or ``TOTs''), like the \code{INumeric} traits of
  Sect.~\ref{sect:type_sets},
\item
  traits with associated types (or ``TATs''), like the \code{INumeric}
  and \code{IAppendable} traits of Sect.~\ref{sect:tats},
\item
  ``universal'' traits, i.e. traits that do not fall into the previous
  two categories (examples of this are all the traits of
  Chapter~\ref{chapt:traits}, and the \code{ISum} trait of
  Sect.~\ref{sect:generic_interfaces}),
\item
  and predefined traits, that can be any of the former three.
\end{itemize}

``Universal'' traits have the least amount of restrictions connected
to them. They can be used together with the \code{class} specifier in
order to declare trait objects (cf. Sect.~\ref{sect:trait_objects}),
i.e. run-time polymorphic variables, or instances of what in type
theory are known as existential types. But they can \emph{also} serve
as generics constraints (as it will be shown in
Sect.~\ref{sect:generic_derived_types}). These traits allow the
programmer to switch from dynamic, to static dispatch of methods (see
the later Sect.~\ref{sect:Fortran_static_dispatch}), and vice versa
(hence their name). In contrast, both TOTs and TATs are presently
(i.e. in the framework of a prototype implementation of this proposal)
\emph{exclusively} intended for use as generics constraints. Hence, a
compiler must ensure that these two trait kinds are \emph{not} used
for any other purpose.

In particular, both TOTs and TATs cannot be used in variable
declarations that make use of the \code{class} specifier, while TOTs
cannot be implemented (in the sense of
Sect.~\ref{sect:implementing_traits}) by derived (i.e. user-defined)
types\footnote{One of the problems here is that any new intrinsic
function for an intrinsic type, that would need to be added to the
language, would change the set of methods of all the type sets of
which this type is a member. This would break any user-defined types
that would implement traits which are based on these type sets.}. In a
future language revision, TOTs could, however, be admitted for use
with the \code{type} declaration specifier to support compile-time
polymorphism through union types \cite{Taylor_21,Pierce_91}, as it is
further elaborated on in Sect.~\ref{sect:union_types}. On the other
hand, TATs could be made ``universal'', and admitted for use with both
the \code{class} and \code{type} specifiers, as in Swift 6.0, which
makes use of the analogous keywords \code{any} and \code{some},
respectively, for the same purpose.


\section{Casts to generic types}

A language like Fortran, that is intended for numeric use, where
conversions between different types are required rather frequently,
must allow one to carry out type conversions also in generic code, in
a manner that is similarly user-friendly as in the Swift and Go
languages, without having to rely on external library
functionality. Moreover, this should be possible \emph{regardless} of
whether the type to be cast to is an intrinsic or user-defined
type. This requires language-built-in mechanisms (that were already
discussed) for requiring the availability of initializer
implementations for types, in a manner that is either implicit (see
the Sect.~\ref{sect:type_sets} on type sets), or explicit (see the
language features that were described in Sects.~\ref{sect:traits},
and \ref{sect:implements_stmt}).

As an example, consider the test problem implementation of
Sect.~\ref{sect:poly_functional}. There, a reduction variable for
summation, \code{s}, needs to be initialized to the zero constant of
a generic type, \code{T}. It should be possible, in Fortran, to
effect this initialization by simply writing an expression like the
following:
\begin{lstlisting}[language=LFortran,style=boxed]
  s = T(0)
\end{lstlisting}  
Which (in this example) implies a cast of the zero constant of the
\code{integer} type into the corresponding zero constant of type
\code{T}, by a call to an appropriate initializer of this latter
generic type.

Notice that if the generic type parameter, \code{T}, is instantiated
at compile time with a language-intrinsic type, then the
``initializer'' to be called by the compiler would actually be
Fortran's built-in function for casts to this type. That is, if
\code{T} is instantiated with, say, the \code{real(real64)} type, then
the compiler would transform \code{s = T(0)} into the following,
final, expression:
\begin{lstlisting}[language=LFortran,style=boxed]
  s = real(0,kind=real64)
\end{lstlisting}

If \code{T} is instantiated, instead, with a derived type, then an
appropriate initializer of this type would need to be invoked. This
could either be the type's default ``structure constructor'', or a
user-provided initializer, either of which would need to take in an
\code{integer}, and return an instance of type \code{T}. In the
absence of an appropriate (language or user-provided) initializer
implementation, the compiler should simply emit an error message, and
abort compilation.

\section{Type inference}

As it will be shown in detail in the next sections, the present design
requires a Fortran compiler to implement type inference, in order to
make it easy for a programer to use generic code. In such a framework,
it is then only natural to support also combined automatic declaration
and initialization of variables, as it is possible in the languages
that were surveyed in Chapter~\ref{chapt:survey}. We propose to adopt
Go's \code{:=} assignment operator for this purpose, as it is
syntactically light-weight, and could thus be easily employed not just
for declaring local variables in a non-intrusive fashion within
sections of regular executable statements, but also within loops
(including the declaration of their indices), e.g. as follows:
\begin{lstlisting}[language=LFortran,style=boxed]
     real :: arr(10)
     do i := 1, 10
        tmp := real(i)
        arr(i) = tmp
     end do
\end{lstlisting}
This last (somewhat concocted) example could also be written as a
single line of code, by embedding an implied \code{do} loop within an
array constructor, and using the \code{:=} operator twice:
\begin{lstlisting}[language=LFortran,style=boxed]
     arr := [(real(i),i:=1,10)]
\end{lstlisting}
The \code{:=} operator is strictly intended for the declaration of
\emph{local} variables in procedures and main programs. Module
variables, and variables that express function return values, aren't
considered local (in Fortran) and are therefore not allowed to be
declared in this way.

\section{Generic entities}
\label{sect:generic_parameters}

The present Swift-inspired generics allow both ordinary and type-bound
procedures (i.e. methods), as well as derived types and their
constructors, to be given their own generic type parameters. Main
programs \emph{cannot} be generically parameterized, as they cannot be
called by any other program unit. Generically parameterized modules
are considered an equally moot concept, given that (in contrast to
derived types) modules are not a part of the type system.

\subsection{Generic procedures}
\label{sect:generic_procedures}

Using the syntax that is proposed in this document, an implementation of a
Fortran function for array summation that is generic over the type of
its input array argument would look as follows\footnote{Generic
subroutines can be coded completely analogously.}:
\begin{lstlisting}[language=LFortran,style=boxed]
  function sum{INumeric :: T}(x) result(s)
     type(T), intent(in) :: x(:)
     type(T)             :: s
     s = T(0)
     do i := 1, size(x)
        s = s + x(i)
     end do
  end function sum
\end{lstlisting}
The following examples will assume that the \code{INumeric} generics
constraint, that is used here for type \code{T}, is provided by a
trait that prescribes either implicitly (see
Sect.~\ref{sect:type_sets}), or explicitly (see
Sect.~\ref{sect:tats}), an appropriate initializer and addition
operator, that are implemented by the \code{integer} and
\code{real(real64)} types.

To actually use the \code{sum} generic function, one simply needs to
pass to it (via its regular arguments list) an argument of one of
these two admitted ``numeric'' types, as in the following calls:
\begin{lstlisting}[language=LFortran,style=boxed]  
  integer_total := sum([1,2,3,4,5])
  double_total  := sum([1.d0,2.d0,3.d0,4.d0,5.d0])
\end{lstlisting}
The compiler will then use automatic type inference to instantiate
appropriate versions of the \code{sum} generic function for each call,
given the types of the provided regular arguments. The programmer can
thus straightforwardly use his generic routine with any of the
admitted types. In this particular example, type inference will
actually be employed not just for calling \code{sum}, but also for
instantiating the variables \code{integer\_total} and
\code{double\_total} via the \code{:=} operator.

Although the present design \emph{doesn't} require it, the programmer
can specify generic type arguments also manually. The following
example demonstrates how both the aforegiven result variables can be
declared, and generic type arguments to the \code{sum} function be
provided, by hand. Notice the use of curly braces for the latter
purpose:
\begin{lstlisting}[language=LFortran,style=boxed]
  integer      :: integer_total
  real(real64) :: double_total

  integer_total = sum{integer}([1,2,3,4,5])
  double_total  = sum{real(real64)}([1.d0,2.d0,3.d0,4.d0,5.d0])
\end{lstlisting}

Manual instantiation of generic procedures is only needed in
the relatively rare cases where a regular arguments list is either
unavailable or outright inappropriate, e.g. for use in procedure
pointer assignments, or in \code{associate} statements, as in the next
example:
\begin{lstlisting}[language=LFortran,style=boxed]
  real(real64) :: dtot(2)
  real(real32) :: stot(2)
  procedure(sum_real64), pointer :: dsum

  abstract interface
     function sum_real64(x) result(s)
        real(real64), intent(in) :: x(:)
        real(real64)             :: s
     end function sum_real64  
  end interface
  
  dsum => sum{real(real64)}
  dtot(1) = dsum([1.d0,2.d0,3.d0,4.d0,5.d0])
  dtot(2) = dsum([2.d0,4.d0,6.d0,8.d0])

  associate( ssum => sum{real(real32)} )
     stot(1) = ssum([1.,2.,3.,4.,5.])
     stot(2) = ssum([2.,4.,6.,8.])     
  end associate
\end{lstlisting}

\subsection{Generic methods}
\label{sect:generic_methods}

The same summation algorithm as that of
Sect.~\ref{sect:generic_procedures}, when implemented as a generic
method, \code{sum}, that is bound to a derived type named
\code{SimpleSum}, which implements the trait \code{ISum} as it was
given in Sect.~\ref{sect:generic_interfaces}, would instead look as
follows:
\begin{lstlisting}[language=LFortran,style=boxed]
module simple_library
   ...
   type, public :: SimpleSum
   end type SimpleSum

   implements ISum :: SimpleSum
      procedure, nopass :: sum
   end implements SimpleSum
   
contains
   
   function sum{INumeric :: T}(x) result(s)
      type(T), intent(in) :: x(:)
      type(T)             :: s
      s = T(0)
      do i := 1, size(x)
         s = s + x(i)
      end do
   end function sum

end module simple_library
\end{lstlisting}

We have used here the \code{implements} statement for implementing a
trait by a derived type, and will continue to consistently do so for
the remainder of this chapter. The alternative way of employing the
\code{implements} derived type attribute for the same purpose, is
demonstrated on the same examples in
Chapter~\ref{chapt:fortran_examples}. Generic methods are used
completely analogously to generic procedures. The automatic
instantiation use case of Sect.~\ref{sect:generic_procedures} would,
for instance, be coded with the help of \code{SimpleSum}'s (default,
structure) constructor as follows:
\begin{lstlisting}[language=LFortran,style=boxed]
  simple := SimpleSum()
  
  integer_total := simple%sum([1,2,3,4,5])
  double_total  := simple%sum([1.d0,2.d0,3.d0,4.d0,5.d0])
\end{lstlisting}
Whereas Sect.~\ref{sect:generic_procedures}'s ``manual'' use case
would take the form:
\begin{lstlisting}[language=LFortran,style=boxed]
  type(SimpleSum) :: simple

  integer      :: integer_total
  real(real64) :: double_total
  
  integer_total = simple%sum{integer}([1,2,3,4,5])
  double_total  = simple%sum{real(real64)}([1.d0,2.d0,3.d0,4.d0,5.d0])
\end{lstlisting}
See also Sects.~\ref{sect:generic_derived_types} and
\ref{sect:param_constructors} for further instantiation examples.

\subsection{Generic derived types}
\label{sect:generic_derived_types}

Generic type parameters lists are also allowed to appear in derived type
definitions, as in the following example, in which the \code{ISum}
trait of Sect.~\ref{sect:generic_interfaces} is implemented by another
derived-type, that is named \code{PairwiseSum}:
\begin{lstlisting}[language=LFortran,style=boxed]
module pairwise_library
   ...   
   type, public :: PairwiseSum{ISum :: U}
      private
      type(U) :: other
   end type PairwiseSum

   implements ISum :: PairwiseSum{ISum :: U}
      initial :: init
      procedure, pass :: sum
   end implements PairwiseSum

contains

   function init(other) result(res)
      type(U), intent(in)  :: other
      type(PairwiseSum{U}) :: res
      res%other = other
   end function init

   function sum{INumeric :: T}(self,x) result(s)
      class(PairwiseSum{U}), intent(in) :: self
      type(T),               intent(in) :: x(:)
      type(T)                           :: s
      if (size(x) <= 2) then
         s = self%other%sum(x)
      else
         m := size(x) / 2
         s = self%sum(x(:m)) + self%sum(x(m+1:))
      end if
   end function sum

end module pairwise_library
\end{lstlisting}

Notice, how type \code{PairwiseSum} depends on a generic type
parameter, \code{U}, that is used within \code{PairwiseSum} in
order to declare a field variable of \code{type(U)}, which is named
\code{other}. As it is indicated by the type constraint on \code{U},
object \code{other} conforms to the \code{ISum} trait itself, and
therefore contains its own implementation of the \code{sum} procedure.

The above example furthermore shows, that a derived type's generic
parameters are accessible within the scopes of its type-bound
initializers and procedures. For instance, type \code{PairwiseSum}'s
method, \code{sum}, can access \code{PairwiseSum}'s generic parameter
\code{U}, e.g. in order to declare its passed-object dummy argument,
\code{self}, to be of \code{class(PairwiseSum\{U\})}. This allows
method \code{sum} to make use of two independently defined generic
type parameters, \code{T} and \code{U}, which grants it increased
flexibility.

The declaration \code{class(PairwiseSum\{U\})} does not imply any
ambiguities or contradictions with respect to compile-time
vs. run-time polymorphism, because substitution semantics apply. At
compile time, the compiler will substitute a set of different type
arguments for the generic parameter \code{U}. Hence, the notation
\code{PairwiseSum\{U\}} really refers to a set of multiple, related,
but \emph{different} \code{PairwiseSum} types (whose only commonality
is that they all implement the \code{ISum} trait, and furthermore
contain different field components that do the same). Of course,
passed-object dummy arguments of any of the different
\code{PairwiseSum} types of this set can then be run-time polymorphic.
In exactly the same manner that passed-object dummy arguments of other
derived types that implement the same trait can be run-time
polymorphic.

The following code snippet finally shows how an object of the
\code{PairwiseSum} type could be declared and instantiated manually
(by substituting its generic type parameter \code{U} by the
\code{SimpleSum} type of Sect.~\ref{sect:generic_methods}), and how
its generic \code{sum} method would be employed using automatic type
inference:
\begin{lstlisting}[language=LFortran,style=boxed]
  type(PairwiseSum{SimpleSum}) :: pairwise

  integer_total := pairwise%sum([1,2,3,4,5])
  double_total  := pairwise%sum([1.d0,2.d0,3.d0,4.d0,5.d0])
\end{lstlisting}

\subsection{Generic constructors}
\label{sect:param_constructors}

If a derived type is parameterized over a generic type, as in the
\code{PairwiseSum} type example of
Sect.~\ref{sect:generic_derived_types}, then any constructors of this
derived type must also be assumed to be implicitly parameterized over
the same generic type. Hence, calls of these constructors, with
specific argument types being provided in curly braces to substitute
the generic type parameters of their derived types, must be valid for
consistency reasons. This must actually hold for both structure
\emph{and} user-defined constructors/initializers -- even if
user-provided implementations of these initializers do \emph{not}
contain explicit, corresponding, generic parameters lists (see the
example provided in Sect.~\ref{sect:generic_derived_types}). These
lists are then understood to be implicitly provided by the compiler
(compare the example calls below, and see also
Sect.~\ref{sect:associated_types_usage}).

For an illustration of this, consider first the following variation of
Sect.~\ref{sect:generic_derived_types}'s last code snippet:
\begin{lstlisting}[language=LFortran,style=boxed]
  pairwise := PairwiseSum(SimpleSum())

  integer_total := pairwise%sum([1,2,3,4,5])
  double_total  := pairwise%sum([1.d0,2.d0,3.d0,4.d0,5.d0])
\end{lstlisting}
Notice, here, the lack of an explicit type declaration for object
\code{pairwise}, the use of the \code{:=} operator, and the call to
type \code{PairwiseSum}'s (user-defined) constructor on the
right-hand-side of the first such assignment. The compiler will take
advantage of this latter call to automatically instantiate object
\code{pairwise} with the \code{PairwiseSum} type through type
inference. 

The above code actually makes use of constructor calls of all the
types that are involved in the present example, namely
\code{PairwiseSum} \emph{and} \code{SimpleSum}, in the standard OO way
of chaining such calls. The compiler will then use constructor
\code{PairwiseSum}'s regular argument, \code{SimpleSum()}, in order to
instantiate the generic field object \code{other}, that is embedded
within the \code{PairwiseSum} type
(cf. Sect.~\ref{sect:generic_derived_types}). By doing so, the
compiler will also infer the generic type parameter of the
\code{PairwiseSum} type, in complete analogy to how type inference
works when calling a generic procedure -- thus making manual
instantiation of any of the involved generic types unnecessary.

However, it is also possible, within the last call, to provide
\code{PairwiseSum}'s generic type argument manually in curly braces,
for the mentioned consistency reasons, as follows:
\begin{lstlisting}[language=LFortran,style=boxed]
  pairwise := PairwiseSum{SimpleSum}(SimpleSum())
\end{lstlisting}
Hence, both of these constructor call variants are valid, and give the
same result. Although the first variant is the one that we actually
recommend for general use (possibly together with the employment of
keyword arguments).


\chapter{Fortran examples}
\label{chapt:fortran_examples}

To comprehensively illustrate how the new features, that were
introduced in the last two chapters, would be used in practice, we will
give in the present chapter several worked out examples. The first two
subsections contain both functional and OO Fortran code versions of
the standard test problem that is used throughout this document. While
the last two subsections deal with how to use operator overloading, and
associated types with generics.

\section{Functional versions of the standard test problem}

Fortran presently lacks support for advanced functional programming
capabilities, like closures and variables of higher-order functions,
that are, e.g., available in Go and other modern languages. In
contrast to the Go version of the standard test problem that is given
in Sect.~\ref{sect:poly_functional}, the functional Fortran code
versions that are presented in this section therefore make no attempt
to eliminate rigid dependencies on user-defined function
implementations, and content themselves with demonstrating how the new
generics features can be used to eliminate rigid dependencies on
language-intrinsic types.

\subsection{Automatic instantiation of generic procedures}

Listing~\ref{lst:Func1Fortran} shows a straightforward generic
functional implementation of the standard test problem, that uses
automatic type inference by the compiler to instantiate its generic
functions. The following additional remarks should help to better
understand this code:
\begin{itemize}
\item
  To express type genericity for the arguments and return values of
  all generic functions, a type constraint is employed that is
  implemented as the type set \code{integer | real(real64)} within a
  trait \code{INumeric}.
\item
  Trait \code{INumeric} is defined by the user, 
  obviating thereby the need for an external dependency.
\item
  Any required conversions to generic types are done using explicit
  casts, as in Go (or Swift).
\item
  \emph{All} the required instantiations of generic procedures are
  performed automatically by the compiler, based on type inference of
  the latters' passed regular arguments.
\item
  Use of type inference is also made in order to simultaneously
  declare and initialize local variables with the \code{:=} assignment
  operator, even within executable statement sections and loops.
\end{itemize}

\lstinputlisting[language=LFortran,style=boxed,label={lst:Func1Fortran},caption={Fortran version of the array averaging problem with
automatic generics instantiation.}]{Code/Fortran/functional1.f90}

The example demonstrates that using the new generics features together
with a functional (or procedural) programming style is easy, that the
syntax is concise, and that type inference by the compiler should
be straightforward and therefore reliable. Hence, we believe that the
generics features, that are described here, will place no burden on the
programmer.

\subsection{Manual instantiation of generic procedures}

It is actually possible to make the Fortran code version that was
given in Listing~\ref{lst:Func1Fortran}, resemble the Go code version
of Listing~\ref{lst:polyfuncGo} a bit closer, by having two procedure
pointers stand in, within the \code{select case} statement of the main
program, for the closures that were used in the Go code. As this is a
good example for demonstrating how generics can be instantiated
manually by the programmer, we give in Listing~\ref{lst:Func2Fortran}
an alternative form of the main program of
Listing~\ref{lst:Func1Fortran} that makes both use of procedure
pointers, and such manual instantiation (as it was discussed in
Sect.~\ref{sect:generic_procedures}).

\lstinputlisting[linerange={50-101},language=LFortran,style=boxed,label={lst:Func2Fortran},caption={Main program using procedure pointers and manual generics instantiation.}]{Code/Fortran/functional2.f90}

\section{Object-oriented versions of the standard test problem}

The present section will demonstrate that being able to use the new
generics features seamlessly and easily, even within a modern-day OO
programming setting, is one of the great strengths of the present
design.

\subsection{Dynamic method dispatch}
\label{sect:Fortran_dynamic_dispatch}

Listing~\ref{lst:OOFortran} shows an encapsulated (i.e. OO) Fortran
code version of the standard test problem, that makes use of dynamic
method dispatch for all user-defined abstract data types (ADTs),
and is therefore comparable to the code versions that were presented
in Chapter~\ref{chapt:survey} for all the other languages.

\begin{itemize}
\item
  As in all these other versions, three interfaces/traits are used to
  manage all the source code dependencies in the problem:
  \code{INumeric}, \code{ISum}, and \code{IAverager}. Trait
  \code{INumeric} is defined here by the user himself as a type set,
  similar to the corresponding Go code (for a version that does not
  use type sets, see the later Sect.~\ref{sect:ocp_conformance}).
\item
  In contrast to the Go and Rust versions (Listings~\ref{lst:OOGo} and
  \ref{lst:OORust}), none of the aforementioned interfaces/traits is
  parameterized itself, since we followed Swift's basic model of
  generics.
\item
  Interface inheritance is expressed through the presence of the
  \code{implements} attribute in derived-type definitions (equivalent
  to the Swift version, Listing~\ref{lst:OOSwift}). Alternatively,
  \code{implements} statements could be used
  (cf. Sects.~\ref{sect:implements_stmt}, \ref{sect:generic_methods},
  and \ref{sect:generic_derived_types}).
\item
  All our derived types are \code{sealed}, which makes them
  inextensible to implementation inheritance, and thus enables us to
  declare the passed-object dummy arguments of their type-bound
  procedures with the \code{type} specifier.
\item
  The example code employs both language- and user-defined
  constructors in its main program, in a manner that is fully
  equivalent to the Swift version, Listing~\ref{lst:OOSwift}.
\item
  This Fortran version makes use of modules and \code{use} statements
  with \code{only} clauses, in order to make explicit the source code
  dependencies of the different user-defined ADTs/classes.
\end{itemize}

\lstinputlisting[language=LFortran,style=boxed,label={lst:OOFortran},caption={Fortran OO version of the array averaging example with dynamic method dispatch.}]{Code/Fortran/mixed.f90}

The most important point to note, in Listing~\ref{lst:OOFortran}, is
how this code makes use of trait objects
(cf. Sect.~\ref{sect:trait_objects}) and generics to avoid rigid
dependencies on user-defined implementation and language-intrinsic
types, respectively, and to thus realize a plugin architecture that
allows for a maximum of code reuse. In particular, the main program is
the only part of the code that (necessarily) depends on
implementations. The \emph{entire} rest of the code is decoupled, that
is it depends merely on traits (i.e. abstract interfaces, see the
\code{use} statements in the above modules).

All the traits that are required for this purpose are defined by the
user himself, without any need to depend on external libraries. The OO
Fortran version, that is presented here, is therefore as clean with
respect to dependency management, and as easy to use, read, and
understand, as the Go and Swift implementations of
Listings~\ref{lst:OOGo} and \ref{lst:OOSwift}, respectively.

\subsection{Static method dispatch}
\label{sect:Fortran_static_dispatch}

One of the greatest benefits of the present design is that, through
the use of generics, polymorphic methods in OO programming can be made
to use static dispatch\footnote{This can be achieved in a compiler by
implementing generic polymorphism either through the technique of
monomorphization, or through the use of ``witness tables'' for
generics that are devirtualized at compile-time through specialization
\cite{Swift_Generics,Swift_Generics,Swift_Generics_Book}. In both
cases, the result is static method dispatch.}. This will enable
inlining of polymorphic methods by Fortran compilers, to potentially
improve code performance. Listing~\ref{lst:staticFortran} gives
minimally changed, alternative, implementations of the modules
\code{pairwise\_library} and \code{averager\_library}, with which the
original versions of these modules in Listing~\ref{lst:OOFortran}
would need to be replaced, to effect static dispatch of the different
\code{sum} methods.

The required changes are confined to a parameterization of the
\code{PairwiseSum} and \code{Averager} derived types, by generic type
parameters, \code{U}, that conform to the (universal) \code{ISum}
trait. These type parameters are then used to declare the field
objects \code{other} and \code{drv} of the \code{PairwiseSum} and
\code{Averager} types, respectively, by means of the \code{type}
specifier. Taken together, these changes signify compile-time
polymorphism for the objects \code{other} and \code{drv} to the
compiler, and hence static dispatch of their methods (whose signatures
were declared in the \code{ISum} trait). Contrast this with the
\code{class} specifier, that was used previously for the declaration
of these former trait objects, to effect run-time polymorphism and
dynamic dispatch of their methods. See also Table~\ref{tab:dispatch}
for a summary of rules regarding method dispatch.

Everything else, especially the declaration of these object variables
as \code{allocatable}s (and their instantiation using chaining of
constructor calls in the main program), was kept the same in order to
demonstrate that static method dispatch does \emph{not} mean that the
actual object instances that contain the methods must be initialized
and their memory allocated at compile-time. (Although in this
particular example this is possible, by simply deleting the
\code{allocatable} attribute from their declarations.) Notice, that
none of the source code dependencies in the \code{use} statements have
changed. That is, the code is \emph{still} fully decoupled, despite
making now use of static dispatch!

\lstinputlisting[linerange={57-128},language=LFortran,style=boxed,label={lst:staticFortran},caption={Minimal required changes to effect static method dispatch of the \code{sum} methods.}]{Code/Fortran/static.f90}

\begin{table}[h]
\centering
\begin{tabular} {L{0.308\textwidth} C{0.308\textwidth} C{0.308\textwidth}}
  \toprule
  \textbf{object declaration} & \textbf{dynamic dispatch} & \textbf{static dispatch} \\
  \midrule
  \code{class(Trait)}       &  always             & never \\
  \code{class(DerivedType)} &  if \code{DerivedType} is \code{extend}ed &
  if \code{DerivedType} is un\code{extend}ed\tablefootnote{Or the method is declared as \code{non\_overridable}.} \\
  \code{type(DerivedType)}  &  never              & always \\
  \code{type(Trait)}  &  ---  & --- \\
  \bottomrule
\end{tabular}
\caption{Correspondence between object declarations and method
  dispatch strategies that would be typically employed by an
  optimizing Fortran compiler according to the present document. A
  dash indicates that the case in question is presently undefined, but
  could be used for future extensions as mentioned in
  Sect.~\ref{sect:restrictions}, and further discussed in
  Sect.~\ref{sect:union_types}.}
\label{tab:dispatch}
\end{table}

The complete source code of this (statically dispatched) version can
be found in the \code{Code} subdirectory that accompanies this
document\footnote{See the file
\code{Code/Fortran/static.f90}.}. Notice, from this complete listing
(or from the original reproduction of the main program in
Listing~\ref{lst:OOFortran}), that the object \code{av} (of
\code{IAverager} type) still needs to make use of run-time (as opposed
to compile-time) polymorphism. Because instances of types that
\emph{differ} from \code{av}'s declared own type must remain
assignable to this variable.

As in corresponding (static method dispatch) Swift and Rust
implementations of the standard test problem, that are not reproduced
here (see the \code{Code} directory for this), the
instantiation (in the main program) of the objects \code{other} and
\code{drv} through constructor calls, has the benefit that the
compiler can infer the correct type arguments, that are required to
automatically instantiate all the involved generic derived types
(cf. Sect~\ref{sect:param_constructors}). Hence (and similar to both
the functional and dynamically dispatched OO code versions of
Listings~\ref{lst:Func1Fortran} and \ref{lst:OOFortran},
respectively), not a single manual instantiation of generics is
necessary, anywhere, also in the statically dispatched version.

%As a final remark, we'd like to emphasize that, on readability
%grounds, a coding style as that given in Listing~\ref{lst:OOFortran}
%is generally preferable over that shown in
%Listing~\ref{lst:staticFortran}. The use of numerous generic type
%parameters can quickly make code unreadable. We'd therefore recommend
%the default use of run-time polymorphism for managing dependencies on
%user-defined types, and the employment of generics for this latter
%task mainly in cases where profiling has shown that static dispatch
%would significantly speed up a program's execution (by allowing method
%inlining by the compiler). Of course, the use of generics to manage
%dependencies on language-intrinsic types remains unaffected by this
%recommendation.

\subsection{Strict conformance to the Open/Closed Principle}
\label{sect:ocp_conformance}

In the examples that were presented so far in this chapter, we made
predominant use of generics constraints that, in the form of the
\code{INumeric} trait, were expressed as (Go-like) type sets of
intrinsic types. As it was already discussed in
Sect.~\ref{sect:Go_encapsulated}, the conciseness of formulation, that
type sets permit, comes at the price of having to give up strict
conformance to the Open/Closed Principle (OCP) of object-oriented
programming.

However, the present design offers the programmer the possibility to
formulate generics constraints also in the alternative manner of
always specifying both the signatures of procedures in abstract
interfaces, and their implementations, explicitly. An example of this
was already given in the form of the (universal) \code{ISum} trait,
that was used as a generics constraint within the derived types
\code{PairwiseSum} and \code{Averager} of
Listing~\ref{lst:staticFortran}. The explicit approach has the
advantage of allowing generic object-oriented code to strictly conform
to the OCP. This can be accomplished independently of the employed
(dynamic or static) method dispatch strategy. Even though we will
confine ourselves here to illustrating this using only
Listing~\ref{lst:OOFortran}, i.e. the dynamically dispatched code
version of the standard test problem, as a baseline.

The following Listing~\ref{lst:OCPFortran} gives the changes that are
required to make the code of Listing~\ref{lst:OOFortran} strictly
conform to the OCP. The \code{INumeric} abstract interface is now
formulated as a trait with associated types, through explicit
specification of the signatures of the type-bound initializer
(i.e. cast function), and the addition and division operators, that
the different summation or averaging methods of
Listing~\ref{lst:OOFortran} require.

Notice, that Fortran's \code{integer} and \code{real(real64)} types
already come with implementations of all this functionality that is
predefined for them by the language. Hence, it suffices to acknowledge
their conformance to the \code{INumeric} trait through empty
\code{implements} statements (that are provided here in the separate
new module \code{intrinsics}). This is fully equivalent to the Swift
implementation that was presented in Listing~\ref{lst:OOSwift}. It is
also equivalent to the Rust example of Sect.~\ref{sect:OORust}, in
that now no pre-existing code needs to be modified, to make this
Fortran version work with additional, new, types. Simply adding a new
module that implements the \code{INumeric} trait for any such new type
is now sufficient.

\lstinputlisting[linerange={1-49},language=LFortran,style=boxed,label={lst:OCPFortran},caption={Required changes to enforce strict conformance of
    Listing~\ref{lst:OOFortran} to the OCP.}]{Code/Fortran/ocp.f90}

When comparing Listing~\ref{lst:OCPFortran} to the more compact (type
set based) code of Listing~\ref{lst:OOFortran}, the need for explicit
provision of empty \code{implements} statements, for all the types
that conform to trait \code{INumeric}, might appear
long-winded. Especially in cases where one would have to deal with a
relatively large number of such types. Such \code{implements}
statements could be completely avoided, though, by adding also
structural (i.e. implicit) subtyping to the design, as it is supported
in Go. See Sect.~\ref{sect:structural_subtyping} for a further
discussion.

\section{Use of overloaded operators with generic procedures}
\label{sect:overloading}

The following Listing~\ref{lst:types} provides a worked out example of
how, in the present design, traits with overloaded operator signatures
can be used with generic routines. This is demonstrated here in terms
of two types, namely a derived type, \code{MyType}, and the
\code{real} intrinsic type. Both of these conform to the traits
\code{IReducible} (with its overloaded multiplication operator
signatures), and \code{IPrintable}, as they are defined in the module
\code{basic\_interfaces}.

Since \code{MyType} and \code{real} conform to the same traits, a set
of common operations can be performed on them. This includes
(\code{elemental}) multiplication of a type with itself, and with
\code{integer} instances, along with casting to, as well as customized
printing of, this type. The generic routines \code{products} and
\code{prod} take advantage of this conformance to carry out a series
of array multiplication and reduction operations, and to print out
their results in an appropriate format, regardless of whether their
argument arrays are of type \code{real} or \code{MyType}.

\lstinputlisting[linerange={1-136},language=LFortran,style=boxed,label={lst:types},caption={Use of an overloaded multiplication operator with different generic procedures.}]{Code/Fortran/overloading.f90}

Of note, here, is the provision of a user-defined initializer for
\code{MyType}, and the use of the \code{static} attribute for binding
actual implementations of \code{operator(*)} to this
type. Derived-type methods that are \code{static}, are bound to the
type itself rather than its instances. Hence, they cannot take any
passed-object arguments, and they must always be dispatched statically.

Notice, also, how none of this is actually required for the
\code{real} type. Because it already comes with suitable,
lan\-guage-defined, implementations of both an intrinsic initializer
for casts to this type, and an elemental multiplication operator -- as
they are required by the \code{IReducible} trait. We therefore had to
merely acknowledge \code{real}'s conformance to this trait. Whereas we
had to provide an own implementation of procedure \code{output}, to
make \code{real} conform to the \code{IPrintable} trait.

Furthermore, and as it was discussed in
Sect.~\ref{sect:implement_intrinsic_type}, the present Fortran
language \emph{rightly prohibits} the programmer (for reasons of
predictability) from overloading the intrinsic numeric operators for
language-intrinsic types! Any attempt by the programmer to provide
some alternative implementation(s) of \code{operator(*)} for the
\code{real} type should thus be treated as an error. The present
generics design makes it easy for a compiler to detect, and ultimately
reject, such an error.

\section{Use of associated types with generic implementing types}
\label{sect:associated_types_usage}

Lastly, we will demonstrate, now, how associated types in traits (as
they were introduced in Sect.~\ref{sect:tats}) can be used in
conjunction with implementing types that are parameterized over some
generic parameter. The following example makes use of the
\code{IAppendable} trait, that was defined in Sect.~\ref{sect:tats},
in order to require an implementing type to provide functionality for
appending items to itself. This trait contains an associated type,
\code{Element}, acting as a placeholder for the type of the appendable
items, that is to be inferred from an actual implementation of that
trait.

\lstinputlisting[language=LFortran,style=boxed]{Code/Fortran/vector.f90}

An example of such an implementation of trait \code{IAppendable} is
provided here by the \code{Vector} derived type. Notice, how the
definition of this type is expressed in terms of the declaration
\code{Vector\{U\}}, that (for the sake of brevity) does \emph{not}
contain an explicitly provided constraint for the type parameter
\code{U}. The latter is therefore, according to
Sect.~\ref{sect:generic_interfaces}, implicitly inferred by the
compiler to conform to the \code{IAnyType} trait. Thus enabling
\code{Vector} to store items of any existing type, \code{U}, within
the generic \code{elements} array that it contains.

Notice, also, that for maintaining consistency between the type,
\code{U}, of the \code{elements} array, and any new \code{item} that we
may wish to append to this array, we must force the \code{item}
argument of method \code{append} to be of type \code{U} as well, as it
is shown in this method's actual implementation. To accomplish this
enforcement without contradicting trait \code{IAppendable}'s
definition (that doesn't know anything about type \code{U}), we made
use of the placeholder (i.e. associated) type \code{Element} in this
trait. Given method \code{append}'s implementation, the compiler will
then infer \code{Element} to be of the actual type \code{U}.

Associated types thus allow one to make traits/abstract interfaces
generic, without having to parameterize either them or their method
signatures by actual generic type parameters, and to thereby entail
the instantiation needs of the latter, and the potential duplication
of client code that this can result in
(cf. Sect.~\ref{sect:Go_encapsulated}). Associated types are therefore
an essential element of the present generics design, and its
philosophy not to burden the user with superfluous manual
instantiations of generics.

This philosophy, of avoiding the manual provision of boilerplate code,
is also evident in the main \code{test\_vector} program of the above
listing. This program demonstrates how to use \code{Vector}s of
different language-intrinsic types, by making use of automatic type
inference -- both in order to determine a \code{Vector}'s appropriate
generic type argument from  its initializer's regular argument, and to
declare actual \code{Vector} instances. Even so, it is important to
provide a consistent user-experience, in cases where the programmer
does decide to provide generic type arguments manually. This is
illustrated in program \code{test\_vector} through the instantiation
of object \code{bools}. There, \code{Vector}'s initializer is called
with a generic type argument, \code{logical}, in curly braces; even
though the user-provided implementation of this initializer does
\emph{not} contain an actual generic parameters list. This list is,
instead, understood to be provided implicitly by the compiler, as it
was explained in Sect.~\ref{sect:param_constructors}.


\chapter{Outlook and final conclusions}

This final chapter lists a number of foreseeable extensions, that
could be added to the present design once a prototype of it is already
successfully implemented.

\section{Rank genericity}

Fortran's special role, as a language that caters to numerical
programming, demands that any generics design for the language must
allow for the possibility to also handle genericity of array rank. The
present design offers a lot of room in this respect, but since this is
a largely orthogonal issue, and since we consider a discussion of such
functionality to be non-essential for the purpose of a very first
prototype implementation of the generics features that were described
here, we defer it to a separate document.

\section{Structural subtyping}
\label{sect:structural_subtyping}

A pretty natural extension of the present design would be to
\emph{supplement} the currently used nominal subtyping with
structural subtyping. The latter could be easily incorporated, by
making lists of interface/trait names optional (rather than mandatory)
when providing trait implementations. The \code{implements} statement,
for instance, would still serve to bind methods (retroactively) to
types, and to provide optional nominal subtyping, whose use would
remain highly recommended, for documentation purposes \cite{MojoRef}.

But in all cases where such nominal subtyping would be intentionally
skipped, e.g. because it might appear more cumbersome, the compiler
would take over. It would infer any traits that a type conforms to,
given the functionality that the type supports. This would, for
instance, allow one to delete the entire \code{module intrinsics} from
the code example of Listing~\ref{lst:OCPFortran}, and to thereby
achieve greater conciseness of formulation, while still maintaining
strict conformance to the Open/Closed Principle. We ranked structural
subtyping as an optional feature, here, mainly in order to ease
prototype implementations of the present design.

\section{Union types}
\label{sect:union_types}

Another natural extension would be to allow both type sets, and traits
that are formulated in terms of them (cf. Sect~\ref{sect:type_sets}),
to be used directly within the \code{type} specifier of variable
declarations. This would offer additional compile-time polymorphism
support, via union types (also called sum types). The example of a
generic \code{sum} function, that was given in
Sect.~\ref{sect:generic_procedures}, could for instance be re-written
in the following, schematic, manner:
\begin{lstlisting}[language=LFortran,style=boxed]
  function sum(x) result(s)
     type(integer(*) | real(*)), intent(in) :: x(:)
     typeof(x)                              :: s
     s = typeof(x)(0)
     do i := 1, size(x)
        s = s + x(i)
     end do
  end function sum
\end{lstlisting}

This no longer employs a generic type parameters list, and instead
makes use of both, a union type, and Fortran~2023's \code{typeof}
declaration specifier, in order to allow this code to be used
with any of the \code{integer} or \code{real} types that the language
supports. An extension of the present design by union types would take
it to its logical conclusion, offer an alternative to generic type
parameters for certain use cases, such as the one shown above, and fill
the gap that is present in Table~\ref{tab:dispatch}.

\section{Conclusions}

The Fortran extensions, that are described in this document for both
run-time and compile-time polymorphism, resulted from the consistent
application of orthogonal language design. That is, significant new
capabilities are provided through the systematic extension of already
existing Fortran features, and their mutual interaction, rather than
the piecemeal addition of mutually incompatible (and superfluous) new
constructs. Indeed, only in one single case (the \code{implements}
statement of Sect.~\ref{sect:implements_stmt}) did we find it
necessary to introduce a major new language feature. But even then, it
was ensured that the new feature would be of \emph{equal} utility in
supporting both compile-time and run-time polymorphism, so that
orthogonality, again, prevailed.

The end result is a language that is both far less verbose, much
easier to use, and incomparably more powerful than that of competing
non-holistic approaches, which prefer to abandon the proven philosophy
of orthogonal design. The presented extensions are fully backwards
compatible with the present Fortran language, and (in stark contrast
to competing approaches) allow for a consistent use of fully
type-checked generics not just in procedural and functional, but
\emph{also} in OO programming settings, \emph{including} the support
of static method dispatch (which can improve the performance of
polymorphic methods by facilitating inlining via the compiler).

Taken together, these capabilities will allow for the uniform
management of source code dependencies on both language-intrinsic and
user-defined types in Fortran. They will enable the Fortran programmer
to write unprecedented modular code, that is on par with the most
modern languages in terms of reusability, and moreover does not
sacrifice any computational performance. The present design achieves
all of this largely \emph{without} requiring manual instantiations of
generics, and it furthermore provides a solid foundation for a number
of possible future extensions, like support for array-rank genericity,
structural subtyping, and compile time polymorphism via union (sum)
types.

\printbibliography

\renewcommand{\abstractname}{Acknowledgements}

\begin{abstract}
  The present extensions for Fortran could not have been devised
  without the guidance we had through the prior work of countless
  developers on the Swift, Go, Rust, Carbon, and Java languages. We
  wish to thank all these developers, even though we can only mention
  here a few of them explicitly by name, who have particularly
  influenced the present effort. Chris Lattner's design of the Swift
  language provided the foundational ideas upon which we built the
  majority of our language extensions for Fortran, including much of
  the modern OO features, and the generics. While Robert Griesemer's,
  Ian Lance Taylor's, and the entire Go team's inspirational work on
  type sets accounts largely not only for our remaining generics
  design, but also for much of its ease of use. Robert also kindly
  provided the original code version from which
  Listing~\ref{lst:polyfuncGo} was derived, and answered the many
  questions we had regarding Go's generics. We are also grateful to
  everyone else who gave us their feedback to our work, in particular
  Chris Lattner, Magne Haveraaen, and Brad Richardson.
\end{abstract}

\end{document}