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.
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.
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.
Other stats libraries (not tied to either R or Python) include Stan, which implements advanced Bayesian and Likelihood inference models. https://mc-stan.org/
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:
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++.
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.
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.