We are happy to announce that LFortran 0.35.0 can now compile all numerical parts of stdlib, with just very minor workarounds, most tests run. All details are in the blog post:
Great job. One question though. How mature is C-Interop support in LFortran. I ask because (as one of the Fortran interface developers) I think that an important code to add to your test harness is the Fortran Interfaces to NetCDF given how widely its used in the CWO (Climate, Weather, Ocean)/Earth Sciences community. Probably up to the level of F2008 would be enough for now but F2018 would also be nice.
@gnikit, good idea. I am hoping later in the year we should be able to compile it as is. We used a version from about half a year ago, so there was probably more development on stdlib since then. Also I don’t want our alpha quality to put pressure on what features to use for stdlib. We test the version with workarounds at LFortran’s CI, so it will always work. Once we reach beta, then it should be ready to start testing it at the CI of stdlib itself I think.
@rwmsu, it’s pretty strong, we should support most of C interoperability of F2008 already. But if you use a lot of OO like finalizers, we are not super strong on that yet, that’s on our TODO for beta.
No OO. Basically Fortran 90 calling Fortran 2003/2008 C-interop code written to replace the old style C-based wrappers with all the associated name-mangling nightmares.
I tried it, here are the results: Compiling netcdf-fortran · Issue #3883 · lfortran/lfortran · GitHub, there are some minor bugs that I worked around and then it compiles a few modules, including the C interfaces. It looks like you are using implicit interface at one place, which we do not allow by default, but we support it with a compiler option. The biggest issue seems to be that you use an interface to a function compiled separately, we still need to implement that use case. We currently work the best with regular modules and “using” functions from modules. Overall it doesn’t seem too bad, you are right that it would be a good use case.
Yes when I wrote the original version of the C-Interop code, TYPE(*) didn’t exist so I had to default to some implicit interfaces in order to handle the NetCDF routines that passed multiple data types as void pointers. I couldn’t put those routines in a module because the compiler would complain about TKR violations. Also, since I had to also support old Fortran 77 code as well as Fortran 90 I couldn’t put a lot of my code directly into a module (I did provide standalone interfaces in a module (sort of a poor mans module/submodule approach)) because it would force F77 users to modify their codes to USE the modules. To be honest, I haven’t looked at the code in several years. I basically “gifted” the code to UCAR with the understanding (at least on my part) that I would be willing to answer questions but since I was busy with my regular job at the time I wouldn’t be able to do any further development (which I assumed UCAR would carry on). Also, UCAR wisely waited until a critical mass of compilers provided reliable support for C-interop before moving on from the old cfortran.h macro files they used until they adopted my code. I think they would take a similar approach to further modifications that removed all the implicit interfaces and moved to TYPE(*) for passing to void pointers. The question they would ask is how reliable are the assumed TYPE and assumed RANK implementations in current compilers and if not enough compilers passed muster they would be hesitant to move to the newer C-interop features.
@R_cubed good point, I haven’t tried it yet with stdlib. I just added it to our “after beta” TODO. I think until we reach beta we should just focus on compilation, to ensure we support everything correctly, and after beta we’ll get the interactive mode working for everything.