certik

LFortran author here. As kergonath said below, both "new" Flang that you linked above, and LFortran started at about the same time. I know the Flang developers well and I am hoping we'll be able to collaborate in the future more. It looks like MLIR would be one option: they are going to use it for Flang and LFortran can have a backend that could also use it.

LFortran's main advantage is that it is interactive, so the parser and semantics has to be a little different. And also we designed it so that it will be quite approachable for people to write tools on top.

One of the authors of stdlib here. I agree with many of your points.

Fortran needs a good compiler, that is why I started LFortran some time ago:

https://lfortran.org/blog/2019/04/why-we-created-lfortran/

and there is also Flang. Both Flang and LFortra are in development. GFortran is currently the most advanced open source compiler.

See our page for the list of all compilers:

https://fortran-lang.org/compilers/

I am one of the authors. We will pre-generate the files into a tarball, so that end users do not have to worry about generating it or have Python installed. Also we'll probably rewrite the preprocessing tool to C++ for robustness and speed. The reason we use it is that we need some easy way to generate the subroutines to work with any array dimension. There are not many other good options.

We are building a curated list of all open source Fortran libraries here: https://fortran-lang.org/packages/

I submitted this PR long time ago: https://github.com/dagwieers/dstat/pull/50 that fixed an important installation issue, and it took the author 5 months to look at it and simply close it without providing any hints how to fix the problem in some other way. So I was discouraged to contribute further to the project.

The main advantage of this approach is that you can use any C++ compiler and the library (in this case Eigen) will work. The disadvantage of this approach is that the code is incomprehensible to average scientists, you must spend a lot of effort to become a C++ expert.

The advantage of Fortran is that the code is simple and comprehensible to average scientist, and yet fast, because the effort goes into the compiler itself. I would also argue it is easier to implement an optimization pass in the compiler than implement optimizations on the template level in C++. The disadvantage is that you need a good Fortran compiler. If your compiler can't run your code on, say, GPU, then suddenly there is not a good path forward. While in C++, there is always a way forward via template metaprogramming: perhaps ugly, but at least it gets the job done.

One of LFortran authors here. Yes, we already have an open issue for exactly this: https://gitlab.com/lfortran/lfortran/issues/42. As you can read there, it's actually not that easy as I first thought. But I think it's very much worth pursuing.

For example, Python's AST is not round-trippable, and that forces people to write alternative parsers such as Parso (https://github.com/davidhalter/parso).

ANTLR should allow to parse all the white space. But the issue is how to represent it in the AST, see the issue for more details. One could have an AST and a parser just for this round-trippable application, but that defeats the purpose. The goal should be to have this part of the compiler so that one can trust that it parses things correctly.

Right now I am concentrating my efforts to finish gfortran compatibility (see the roadmap at https://lfortran.org) and to get first users. Once we get further along, we will tackle this problem. I am hopeful there might be a way to do this.

The best open source implementation is GFortran. Just make sure you use a recent version, as others mentioned.

Regarding commercial implementations, I only have experience with Intel and NAG, both of which are very good.

No worries. Yes, ultimately down the road in couple years, if there is some agreed upon way of extending Fortran to handle GPU well, the best way is to get it into the Fortran standard itself, that way all compilers will eventually support it. I recently became the Fortran Standard Committee member, so when the time is right, I will try to help on this front. Right now it's too early, first we need to implement the new capabilities in some compilers and get some experience and agreement among users. My own first goal is to get LFortran polished enough to get first users.

Yes, I was planning to start with what NumBa (http://numba.pydata.org/) is doing, they also use the LLVM PTX backend.

There is a really promising new project by Chris Lattner (the original author of LLVM) called MLIR: https://github.com/tensorflow/mlir. That might be the best intermediate representation that all the compilers (Julia, Fortran, ...) could target.

One of LFortran authors here. You raised a good point. I would say for numerical computing, if performance is an issue, the best candidates are C++, Julia, Chapel and Fortran. Each has pros and cons, I am going to post a blog post about that, I didn't want to get into language comparison details in the announcement.

One of LFortran authors here. You have a very good point. We are going to publish a new blog post answering this exact question.

In the meantime, others in this thread pretty much hit all the main points already why Fortran as a language is still a very good choice for numerical computing. It's the tooling that must improve.

I am one of LFortran authors. We just open sourced it recently. Do you have any recommendations if we should create a mailinglist, or rather use something like Discourse? Or both.

Right now if you have any questions, you can open an issue at our GitLab repository:

https://gitlab.com/lfortran/lfortran

I am one of the LFortran authors.

Can you please point me to some documentation or examples where Intel Fortran is used to offload to, say, NVIDIA GPUs? I don't think it supports it yet.

PGI and IBM support CUDA Fortran, other compilers don't. PGI/Flang has an experimental support for offloading "do concurrent". Some compilers also support the openmp/openacc pragmas and GPU offloading. One can also call CUDA C from any Fortran compiler via iso_c_binding. None of this is ideal.

I think it's still a research problem how to best integrate GPU support in the language itself. CUDA Fortran is nice --- one thing we want to do down the road is to implement CUDA Fortran and to allow LFortran to transform code it understands into a Fortran dialect that all Fortran compilers can compile, so that one can use any Fortran compiler and still use CUDA Fortran.

The other path is to parallelize "do concurrent", but part of this is also means to extend Fortran to allow to specify the array layout, as Kokkos (https://github.com/kokkos/kokkos) allows.

That is one of the biggest problem with Fortran: people want to be assured that their code will run on modern hardware. When using, e.g., C++ and Kokkos, then there is some assurance that the code will run.

Regarding the fixed-form parser, I think that's a good idea. I just created an issue for it: https://gitlab.com/lfortran/lfortran/issues/82.

I see what you mean --- that's just a for loop. I created an issue for it: https://gitlab.com/lfortran/lfortran/issues/83.

Thanks for the feedback!

> Does it support "intersection format"?

It doesn't yet. Are you interested in this for parsing or for code generation?

If for code generation (i.e., LFortran parses your Fortran code, and then generates a Fortran code back in this format), then I think that will not be that difficult to implement, I think this would be useful.

Regarding parsing, for now my parser is for free form. But I think it would be useful to also have a fixed form parser --- it might need to be a separate parser, but the rest of LFortran can be reused.

> Does it have a linter that can remove linenumbers in the easy cases?

Can you give an example of what you mean?

One issue with linting is that currently the parser is not round-trippable (https://gitlab.com/lfortran/lfortran/issues/42). That means that it can generate the original code back, but it will be formatted differently (mostly white space). Most compilers are not round-trippable. The only compiler that I know about that is round-trippable is C#. Essentially one has to keep track of white space and other formatting, and I didn't want this to complicate the internal representation. I wanted to design the internal representation that is as simple as possible. And then see if one can add optional nodes for white space, similarly how C# does it. If it's possible, then I'll do it.

However, even if it is not round-trippable, the linter can simply generate a nice Fortran code back, and if people use the linter like `clang-format`, enforced by the CI, then it might not be a problem.

Here is the current implementation of ASR (Abstract Semantic Representation) to AST (Abstract Semantic Tree):

https://gitlab.com/lfortran/lfortran/blob/f5856fadf8bd0cc479...

And AST to source code:

https://gitlab.com/lfortran/lfortran/blob/f5856fadf8bd0cc479...

We will be extending it this summer to support more Fortran features.

It's mostly about priority at this point --- I want all of the above to be implemented, it's just about what I do first and what second. Feel free to vote or open new issues here:

https://gitlab.com/lfortran/lfortran/issues

See also my current roadmap/priorities at the bottom of:

https://lfortran.org/

I am one of the authors, I am happy to answer any questions.

I just opensourced LFortran that provides a REPL for Fortran, among other things: https://gitlab.com/lfortran/lfortran, only a subset of Fortran is supported for now, but it's a start. Here is a demo in a Jupyter notebook: https://nbviewer.jupyter.org/gist/certik/f1d28a486510810d824....

The motivation is precisely as you described. In fact, Julia was my initial motivation too: but I didn't want a new language, I wanted the modern interactive environment for Fortran.

In order to get first users and before full Fortran 2018 is supported, I figured out how to parse GFortran's mod files and can interface to GFortran's array descriptors, I am now integrating it in the interactive compiler / REPL. After that is done, for a subset of Fortran, I think this will already be usable (one could use GFortran to compile production code, and use LFortran to use parts of it interactively) and I will announce it more widely. I think this will happen in the next few months.