Appetite for common Fortran parsing library?

[ZedThree]

Along with the original developer @cmacmackin, I'm one of the maintainers on FORD, a Fortran documentation generator, and our parsing module is starting to get a bit old and creaky.

Is there any appetite among the fortls developers to work on a common parsing library that both our tools could use? There are a few other tools such as fprettify that might also benefit from having such a library.

[cmacmackin]

I'm planning to apply for a grant that would fund the work to refactor FORD's parser, preferably using the flang parser as a backend. If I could get some collaborators for turning that into an external library then that would be great. If I use flang then that also has the advantage of being in C++ and thus faster than Python. It's not a huge issue for FORD but is beneficial for a language server.

…

On Fri, 3 Sep 2021, 12:11 Peter Hill, ***@***.***> wrote: Along with the original developer @cmacmackin <https://github.com/cmacmackin>, I'm one of the maintainers on FORD <https://github.com/Fortran-FOSS-Programmers/ford>, a Fortran documentation generator, and our parsing module is starting to get a bit old and creaky. Is there any appetite among the fortls developers to work on a common parsing library that both our tools could use? There are a few other tools such as fprettify that might also benefit from having such a library. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#205>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB6ESPMSOEXDJQQ4IE4A7MDUACUOHANCNFSM5DLQ3GMQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[michaelkonecny]

Are you guys aware of LFortran?
It says it can now parse any Fortran 2018 syntax to an Abstract Syntax Tree and format it back.
Maybe it could be useful somehow.

I didn't have a chance to test it yet, but I'm a big fan of the author's (Ondřej Čertík's) efforts (also fortran-lang.org).

[cmacmackin]

I've examined the source code for both LFortran and Flang. My conclusion is that, while LFortran is quicker and easier to build the code looks much harder to understand and develop. Parts of it appear to be written more like C than C++. Flang has some slightly unintuitive bits but is very much written according to modern C++ conventions, making it much easier to follow. It also already seems to have quite a good ability to extract information on all of the symbols defined in the code. Another advantage of Flang is that it provides much better information about locations in source files, properly accounting for included files, line continuations, etc (whereas Lfortran just normalises everything to be like a single file without line continuations and gives line numbers based on this). The main downside of Flang is that the contribution process looks more difficult, should any modification to the main library be required (discussion occurs via mailing lists, contributors send in patches, etc.). The biggest thing that would need changing would be pulling out comments from source code (Flang doesn't do this but there is an approach we could borrow from Clang) and to do this efficiently I'm pretty sure would require modifying Flang itself (or else doing some sort of monkey-patching by hacking include and link paths at build-time).