The problem, as someone pointed out earlier, is the lack of connection and development between the standard committee and a compiler to implement all the features that are proposed or accepted.
So we are left with the vendors adopting and implementing things, this is why do concurrent is implemented differently in the Nvidia, amd, cray, and gnu compilers.
Fortran can do GPUs but portability across vendors is not a given. Kokkos attempts this and mostly succeeds because C++ got premier support during the first big GPU push.
I think that sums up the issue. A language without good handling of unstructured data is not a modern language, period. As far as I know, LFortran is the only compiler that does provide some implentation of a hashmap, although not standardized.
Not rewrite but modernize enough to provide a bind(C) interface and a Python ctypes binding. Claude struggled with understanding fortran rules (for example regarding common block declarations). I would say we managed to get it done the 5th time, but it required frequent corrections. It was an old code from '82 with dozens of common variables and LLM was very good at following all the dependencies, but tight guidance over architecture of the solution was needed. “Autonomous coding agents” are incovenient to me for one reason: they make decisions I disagree with requiring rollback and waste of tokens, I prefer much tighter control and checking their every step.
It is 100% pure Fortran, the usual pyplot-style API, and it has svg, png, pdf (and even gif!) backends, the backends are all in pure Fortran, they generate the svg text, or png/pdf/gif binary. I embed the glyphs of a font directly into Fortran sources, support latex-style math rendering, etc.
I needed something to use in the JupyterLite notebooks that LFortran now supports, so since it runs in the browser and must be fast, I needed to generate svg/png directly in pure Fortran.
Anyway, it was super easy to do this thanks to AI, so I think we can now have the full ecosystem from plotting, file formats everything in pure Fortran.
In my transpilers to Fortran I skip plotting code, but eventually I would like to translate simple plotting code from R and Python, maybe using fplot. There is already a project by the same name using Gnuplot. You could consider renaming your project to avoid confusion.
I had just opened an issue about that. Perhaps a matplotlib-inspired fplotlib (or similar) would not just avoid confusion but also be fitting to signal its similarity to matplotlib.
Christopher and I also prototyped using the vega-lite JSON format as the intermediate representation of plots, which allows to have different frontends (in different languages) and different backends. But I still don’t know if it is worth it or not, and if there are performance implications of using JSON in the middle (I think we would need to figure out how to keep the data itself in internal datastructures, just reference it from JSON, for speed). Now when we figured out how to do everything in pure Fortran, perhaps it’s less important to have a clean intermediate representation.
One thing we can also try to figure out is to have various independent fpm packages for fonts, png, gif, etc. output. I think those would be useful to other libraries also.