Modify goal and workflow of stdlib

[ivan-pi]

Currently the front page of stdlib states:

stdlib is both a specification and a reference implementation. [...] if the Committee wants to standardize some feature already available in stdlib, it would base it on stdlib's implementation.

As I understand things, the Fortran committee has little to do with the actual implementation. Instead this is primarily a job of the compiler vendors (of course they are able to influence the standardization process to some degree). On the other hand the committee has everything to do with the specification which defines the interface and the behavior.

Since the introduction of submodules, the interface part, and the implementation (behavior) can be decoupled from each other. For the language users who are willing to use a compatible C/C++ compiler (meaning the majority of currently available compilers) this provides an opportunity to speed development efforts by interfacing with external libraries such as the C++ standard library, Boost, libm, and other respected sources, in order to converge to a specification faster.

The current work flow document asks contributors to present a draft Fortran implementation in stage 3. I am wondering if we could agree to a modified work flow that would allow contributors to still propose an experimental Fortran API, but draft the implementation in C or C++ potentially with external dependencies? A reasonable requirement for the routine to move out of experimental would still be a Fortran implementation, as an assurance that Fortran can "stand on it's own".

I realize this approach has many downsides, e. g. having to maintain a mixed Fortran/C/C++ repository, introduce a bunch of preprocessor commands and optional flags, increase the potential for memory leaks and C related bugs, and finally introduced unwanted dependencies to the project.

[milancurcic]

I think that if we can agree (on a case by case basis) that the pros of a C or C++ implementation outweigh the cons (which you listed), that's fine with me. Fortran compilers usually come with companion C and C++ compilers, so it wouldn't impact compiling from source for developers, and it wouldn't impact users who download the binary files.

But I don't see why this needs the workflow to be modified. Does the workflow doc say that the implementation must be in Fortran? The specification would describe the Fortran API, which you'd need to have regardless of the implementation language under the hood.

[ivan-pi]

But I don't see why this needs the workflow to be modified. Does the workflow doc say that the implementation must be in Fortran?

On more careful reading it actually doesn't. It only says "a reference implementation" should be provided.

The primary advantage I see is that the C code might be already available. As an example to develop and test an efficient Fortran sorting function from scratch would likely take someone several man-hours/days. If we could agree to Fortranic interface and just use the C qsort function for our implementation we could have a fast and verified sorting routine sooner. qsort is in fact already allowed as a non-standard extension in some compilers, however the interface is bothersome.

(The article Engineering a Sort Function by Bentley & McIlroy from Bell laboratories explains the trickery that actually goes into a performant sort function.)