Which implementation languages can be used in stdlib

[certik]

Obviously Fortran.

In #19, it looks like also using C might be beneficial.

I was hoping to avoid depending on C++, because that will make stdlib much simpler to distribute (and statically link, etc.). Down the road I would like stdlib to be shipped by default with compilers. So to make it as simple as possible to distribute will be key.

Even simpler would be if we can stay in pure Fortran, but I don't know if we can do that.

[certik]

Related to this is what dependencies we can have. In #10 we will have to depend on a LAPACK implementation. The reference Lapack is in pure Fortran, but we want to be able to link to optimized implementations such as OpenBLAS and MKL. The same with FFT (#21), we can use FFTPACK (Fortran), but we should also allow linking with other implementations such as MKL or FFTW.

[milancurcic]

I agree, the general principle we could take:

• Implement anything we can in Fortran;
• Defer to C for things that we have to;
• Any other language and tool, think and discuss hard and long why it's needed

I can't think of what we'd need C++ for, unless we were writing a Fortran interface to an existing C++ library.

I think this also touches on build systems discussed in #2. Adding a foreign language tool or library increases the complexity of the project (both for us and for users) by more than just the sum of the parts.

[certik]

Agreed. Regarding C, what do we need to use C for besides #19? For example in #21 there are Fortran implementations, so we do not need C there.

I think we might need C to implement low level system dependent access to files, processes, etc. as suggested in https://github.com/fortran-lang/stdlib/issues/14#issuecomment-567536645.

[milancurcic]

As of right now only #19 is looking in that direction. If a POSIX proposal is more seriously considered, that may still be just a set of interfaces with iso_c_binding, so still Fortran.

[cmacmackin]

Related to this is what dependencies we can have. In #10 we will have to depend on a LAPACK implementation. The reference Lapack is in pure Fortran, but we want to be able to link to optimized implementations such as OpenBLAS and MKL. The same with FFT, we can use FFTPACK (Fortran), but we should also allow linking with other implementations such as MKL or FFTW.

Something to keep in mind with FFTW is that it is under the GPL (very unusual for a library). Therefore, if we provide a wrapper able to link against it, it is very important that this be optional so non-GPL software can still use it. Or we could just license all of stdlib under GPL, which I wouldn't object to but I suspect most others will ;)

[certik]

Something to keep in mind with FFTW is that it is under the GPL (very unusual for a library). Therefore, if we provide a wrapper able to link against it, it is very important that this be optional so non-GPL software can still use it. Or we could just license all of stdlib under GPL, which I wouldn't object to but I suspect most others will ;)

Yes. The plan is to only depend on MIT or BSD licensed libraries by default. Then we can have optional wrappers for other libraries like MKL or FFTW, and since they are optional, and stdlib works perfectly fine without them, we can keep our MIT license for stdlib.

[certik]

@milancurcic even in #19 it looks like we'll probably stay in Fortran. So why don't we try hard to stay in Fortran and see if that works for us. That would make things very simple. If we cannot do that, then let's revisit.

[marshallward]

I agree that the reference implementation should use Fortran as much as possible. If there are cases where it cannot be used, then it will highlight a critical limitation of the language, and allow the issue to be handed to the standards committee.

But certainly other implementations, say from vendors, should not feel obliged to use Fortran.

[certik]

@marshallward good point. I think this stdlib can act as a reference implementation, like the reference Lapack implementation (in Fortran). Then vendors can provide more optimized versions and they do not need to use Fortran, as long as they provide the same API.

[ivan-pi]

I would also try to stick with Fortran and C for the beginning. Not only can it be a reference implementation, but hopefully also a good example of what modern Fortran code should look like.

[ivan-pi]

Having just said that, I would like to hear your opinions on are we willing to wrap any F77 code with modern interfaces? I can guess the opinion of @jacobwilliams already :stuck_out_tongue_closed_eyes:

I suspect that at some point, we will end up refactoring some old Fortran routines (the first two examples that come to my mind are the good ol' zeroin and fmin functions).

[certik]

@ivan-pi I think the answer is that for the API, we should use modern Fortran API (modules, assumed-shape arrays, etc.). How things are actually implemented underneath do not matter as much --- we can start with F77, then refactor later if needed. In fact, vendors might provide their own optimized implementations in other languages.

[jacobwilliams]

@ivan-pi I will die a little inside for every fixed-format Fortran file that gets added. 🤣

But, yes, my preference would be to modernize any old code. At a bare minimum, convert any fixed-form to free-form style. The library should be an example of what good, modern Fortran code should look like. And I already have modernized versions of zeroin and fmin!

[MarDiehl]

I would also prefer to rely on modern Fortran and use C-bindings to system-related functionality whenever needed.