FIrst of all, kudos to the lfortran community for this effort!
A little offtopic: one modernization project which might have a very big impact also beyond SciPy could be ARPACK. AFAIK, ARPACK is basically everywhere until today (R, Matlab, Scipy/sklearn, …) but running it on top of different BLAS/LAPACK implementations reliably is just never ending pain (especially for complex types). See for example how in this discussion on SciPy a possible deprecation is proposed for the first time. Recently, PROPACK was added to SciPy which causes even more headache.
I guess that this might be an even bigger undertaking than MINPACK but would like to hear some opinions of Fortran aficionados.
In PZNEUPD, go to is used to jump to end of the routine. Typically, older codes would use this pattern to handle exceptions at the end of the routine. Here the jumps could be replaced with return statements. There are several other things which could be improved here, the question is just who is willing to volunteer their time or sponsor the work financially.
Speaking of goto, I can recommend the following reading for a more balanced view of how good (or bad) it is:
I was not implying that the code is bad, just pointing out that is not really modernized yet
Anyway thank you very much for the links, as someone who took his first coding lecture in 2013 and seen the first fortran line in 2020 I knew very little about old practices. I found all the reads quite informative and fascinating!
I can certainly imagine a future where any time I find a useful Julia code, I transpile it and include it in my existing Fortran programs. Julia has been profiting from existing Fortran libraries, so doing it the other way round should be possible too.
If anyone’s interested, here are some links to David Gleich’s pages and GenericArpack.jl:
2021-04-21: A small project to do a pure port of ARPACK Symmetric solver to Julia - Part 1 - Goals
2021-04-22: A small project to do a pure port of ARPACK Symmetric solver to Julia - Part 2 - Overview
2021-04-29: A small project to do a pure port of ARPACK Symmetric solver to Julia - Part 3 - First routine
2021-05-13: A small project to do a pure port of ARPACK Symmetric solver to Julia - Part 4 - Checking against libarpack
2021-05-18: A small project to do a pure port of ARPACK Symmetric solver to Julia - Part 5 - Understanding Ref
2021-05-26: A small project to do a pure port of ARPACK Symmetric solver to Julia - Part 6 - Sorting Take 1
2021-06-17: Me on learning about save variables in Fortran and accessing them from Julia. (Part … something … in my ongoing segment on porting ARPACK to Julia)
2021-06-24: ARPACK Sorting Take 2 (Part … blah in the ongoing series…)
2021-06-28: LAPACK’s random number generators in Julia (part … blah … in work to port ARPACK to Julia.)
Why bother translating back? If the Julia is simple enough to automatically translate to fortran, you can probably just use StaticCompiler.jl to compile the julia to a binary directly.
That would be fine too. I see the StaticCompiler.jl package originated from the need to include some code in Python. In the case where binary linking is possible, it would be nice to at least to automatically generate the Fortran interfaces.
Fortran compilers which can run on Windows include Intel Fortran, GNU Fortran (via cygwin, mingw, or mingw-64), NAG, Silverfrost FTN95 (targetting .Net), Absoft, just to mention a few out of several others.
Other reasons would be project-specific restrictions and guidelines, etc… I could probably find a few more perma-computing related reasons: “If the new software no longer runs on old hardware, it is worse than old software.”