Reviewers and maintainers needed for stdlib

Meta
21

I see. It seems the Fortran rewrite might be more difficult. So I think for now we should simply depend on fypp to be in PATH and fpm will call it automatically on .fypp files and take care of everything else, so you just do fpm build or fpm test and things will re-generate / recompile automatically under the hood.

In a separate issue we can brainstorm what it would take to rewrite into Fortran. I proposed this to our monthly Fortran call: Fortran Monthly Call: July 2021 - #5 by certik

2 Likes
22

Just a quick comment on that: fypp is only 3000 lines of code, because it uses Pythons eval() to parse all expressions in the directives. Writing that in Fortran would take several thousands of lines more IMO. If one wanted to rewrite it in Fortran, one should probably first collect the expressions used in various projects (especially in stdlib), prioritize them and try to implement in Fortran. Here a couple of examples I use in various projects and would require some effort to parse and interprete:

# Nested list-like structures (one can loop over)
[('complex', 'Cplx'), ('real', 'Real')]

# String repetition/combination
":" + ",:" * (rank - 1)

# Character replacement (to escape quotes)
COND.replace('"', '""')

Additionally, I am heavily using Python constructs (regular expressions, lists, dictionaries) in the implementation. It all can be for sure implemented differently and more Fortran-like, but it could take a while, I fear…

4 Likes
23

One option is to modify the syntax to make it easier to implement in Fortran. I created a separate topic for just that:

Based on the use cases, it seems the main reason we use fypp is due to the lack of generics in Fortran, both for any integer/real/complex type and kind, and also any array rank. If we design a pre-processor to handle just that, that might take care of almost all of the use cases in stdlib.

2 Likes