Should C origins of Fortran language bindings be "hidden"?

When working on my (still not complete) Fortran language binding, I found the effort associated with creating the interfaces acceptable and the library to be rather reasonably usable.

However, it feels a bit like programming C within Fortran, e.g., there are Fortran bindings for fopen and one has to put a c_null_char after each Fortran string.

What is your opinion: Under what circumstances should a language binding “hide” the C origin of a library or not?

Here are some points pro and contra hiding that have come into my mind:

Pro hiding:

  • Feels more like a “real” Fortran library.

  • Easier for people not familiar with C or C++.

  • Prevents errors like forgetting c_null_char

  • Increases readability of the code

  • The “C within Fortran” does not have to be
    explained in the user documentation

Contra hiding:

  • More effort, additional wrapper functions have to be written instead of just interfaces.

  • More effort per library means less libraries are ported or updated (a lot of the work is done by people on their free time or as a small side project within an academic project)

  • Possibility to introduce new bugs.

  • Additional documentation for the Fortran specific routines has to be written and maintained. Otherwise the documentation of the C library can be used by people with a basic understanding of C.

  • Makes the (semi-)automatic generation of interfaces harder.

Open points:

  • Do you thik most Fortran users have and should have a basic understanding of C (I tend to"yes" as an answer) ?

I am weĺl aware that there is no clear yes or no. For
example C macros need more or less to be wrapped around.


They should be hidden if possible.

MPI and PETSc also has similar requirements for c pointers, and I don’t like such bindings too much.

But it’s also important to realize that the responsibility of hiding such C nature falls upon us(i.e Fortran users), and we should create abstractions on top of their code, so it becomes easy to use for Fortran users.

A great example of this is the Focal OpenCL library, that creates a modern Fortran abstraction of CLFortran, and makes it easier to use: GitHub - LKedward/focal: A modern Fortran abstraction layer for OpenCL

1 Like

Indeed, for example in the case of gtk-fortran, programming a GTK GUI in Fortran mimics what you would have written in C. Hiding the C things and offering the Fortran way is a good principle, but in that specific case I will not do it just because the interfaces are automatically generated and their number is ~10 000. Having some knowledge of C is therefore better to use it. I hope it is not essential but sure it helps understanding the reasons why you must write certain things.


That is really an interesting library!

I’m generally trying to hide the C stuff, i.e. the caller don’t have to use iso_c_binding… unless it leads to too many complications

1 Like

I have mixed feelings about adding extra layers of abstraction. In some cases, such as posix system calls, the api is defined in terms of C, and I think the best approach for a fortran programmer is to work as closely to that defined api as possible with no extra layers. In other cases, such as a graphics library, the api is often complicated and uses features that are not directly accessible from fortran, so interface layers are required.


To answer the question in your title: in the ideal world “yes”, they should be. In the actually existing world, that is often not possible.

This is a question I’ve struggled with, to the point I’m seriously using C before going back to Fortran. I think at the current time in Fortran’s evolution, there is simply too much C code for common tasks, that it is inevitable that one will have to deal with C concepts at some point.

This overwhelming need to interface with C to do anything practical, makes learning (and teaching) intermediate and advanced Fortran programming a challenge. How should Fortran be introduced in relation to C? Can common data structures and algorithms be implemented without using c_ptr, for example? I think using it as a DSL for numerical computing is very reasonable, but I would not want to discourage people who want a more “native” Fortran ecosystem for other contexts.

Hopefully, the Modern Fortran community grows to the point where most common tasks can be done in Fortran alone, without needing to complicate teaching things by referring to C, although I admit C is growing on me.

1 Like

Could you list which are the common tasks you have in mind or are currently missing?

It would be nice to have:

  1. A modern stats library. I’ve been studying the apophenia library implemented in C with GNU Scientific Library (GSL). It broadens the concept of a “model” to include notions such as agent based models.

The premise of the library unifies a number of areas via notions from modern algebra.

He describes the reason for the book in this blog post: Reason for the Book

A detailed textbook is available on how to use the library.
Modeling with Data: About the Book

Other stats libraries (not tied to either R or Python) include Stan, which implements advanced Bayesian and Likelihood inference models.

  1. Financial modelling, A widely used library (implemented in C++) in a number of areas is:

Such a library would be very helpful for use in Fortran for computation in risk management. I’d like Fortran examples of procedures in this text:

  1. A parser generator. Flex/Bison is typical if you want to quickly implement a parser for an input language, but they only output C or C++.

  2. Some attention on how to do network/web programming would be useful, but likely well outside of the scope of the Fortran community. The BCHS project by some OpenBSD contributors is remarkably similar to the Fortran Machine project, right down to the use of (Fast)CGI on the server end.

Could all of this stuff (except maybe Flex/Bison) been done in Fortran? Absolutely. But it wasn’t, and rather than write wrappers for these things (especially C++), one has to decide what priorities to emphasize. I emphasize using computers to explore applied math and statistics topics. Fortran would be ideal, but the library situation is problematic, and I need to learn more from other areas before I can help improve the Fortran ecosystem.

I think that it depends on the type of library. In libraries dealing mainly with mathematical problems implementing the functionality in pure Fortran makes sense, where in other fields (GUI, networking, System programming) there already exist “canonical” C APIs with wrappers for a lot of other languages.

I do not think trying to reimplement/mimic GTK or Posix (for example) independently of the underlying C libraries makes any sense (if it is even possible.)

In the latter case I think this should not be considered a real flaw of Fortran as this is true for almost all programming languages.


I agree, but what should one do when a lot of well tested numerical code is available in C for example? The GNU Scientific Library could have been written in Fortran, but ANSI C was chosen instead. There is likely Fortran code scattered around the 'net that would accomplish all of those tasks, but GSL has them all in a unified package. This has implications for teaching the language, particularly to high school or first year undergrad students.

The following project exists – I have not used it.


I’ve known about it for awhile; I’d use it if I were going to write stats routines myself in Fortran. IIRC, the ROOT data analysis software also uses it (or at least permits access to it). They even wrote a C++ interpreter Cling, for use with exploratory data analysis. Here is where LFortran’s interactive capabilities would be very interesting.

But to use the apophenia library mentioned above, I’d have to bind a few hundred functions.