5 ms·

Why we created LFortran

12 points by johndcook 7y ago

certik 7y ago
I am one of the authors, I am happy to answer any questions.
gus_massa 7y ago
Bonus points for: > Automatic transformation of code to older Fortran standard that other Fortran compilers can compile — allowing developers to use the latest standard, and still be able to use current Fortran compilers Sometimes I have to make programs that run in machines nobody is sure about the configuration details. Does it support "intersection format"? http://fortranwiki.org/fortran/show/Continuation+lines http://fortranwiki.org/fortran/show/Continuation+lines Does it have a linter that can remove linenumbers in the easy cases?
- certik 7y ago
  > 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 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/f5856fadf8bd0cc4792d57d0b7b5a835cc8555b8/lfortran/asr/asr_to_ast.py https://gitlab.com/lfortran/lfortran/blob/f5856fadf8bd0cc479... And AST to source code: https://gitlab.com/lfortran/lfortran/blob/f5856fadf8bd0cc4792d57d0b7b5a835cc8555b8/lfortran/ast/ast_to_src.py 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 https://gitlab.com/lfortran/lfortran/issues See also my current roadmap/priorities at the bottom of: https://lfortran.org/ https://lfortran.org/
  - gus_massa 7y ago
    I suggested intersection format for the code generator part. Also, there is a huge amount of legacy code flying around. Write the fixed form parser as soon as you can. An example of legacy code with linenumbers is: (Extracted from real code, I only changed the variable names.) do 1 i = 1 , n do 1 j = 1 , n if(x(i,j).ne.y(I,j)) print*,x(i,j),y(j,i) 1 continue
    - certik 7y ago
      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 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 https://gitlab.com/lfortran/lfortran/issues/83. Thanks for the feedback!
      - gus_massa 7y ago
        I've also seen weird controlflow using linenumbers, I pick an easy but common one. I don't expect that the program can handle all the cases and produce something sane. But most of the cases I saw are easily fixable with an enddo or endif.
bocklund 7y ago
Almost all the cases under the “How to fix that” heading seem addressed by Julia, but also MATLAB or Python if performance is not an issue. As a PhD student who heavily relies on highly optimized Fortran code and who has spent time translating small Fortran projects to Python+NumPy, I don’t understand why anyone would start a new project in Fortran. The only people I know who write Fortran do it because of legacy code or because that’s the only language they know. Since calling Fortran is fairly well supported for languages used in/designed for science (Python, MATLAB, Julia), I don’t see legacy code being as big a driver.
- certik 7y ago
  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.

12 points by johndcook 7y ago

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

Bonus points for: > Automatic transformation of code to older Fortran standard that other Fortran compilers can compile — allowing developers to use the latest standard, and still be able to use current Fortran compilers Sometimes I have to make programs that run in machines nobody is sure about the configuration details. Does it support "intersection format"? http://fortranwiki.org/fortran/show/Continuation+lines http://fortranwiki.org/fortran/show/Continuation+lines Does it have a linter that can remove linenumbers in the easy cases?

certik 7y ago
> 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 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/f5856fadf8bd0cc4792d57d0b7b5a835cc8555b8/lfortran/asr/asr_to_ast.py https://gitlab.com/lfortran/lfortran/blob/f5856fadf8bd0cc479... And AST to source code: https://gitlab.com/lfortran/lfortran/blob/f5856fadf8bd0cc4792d57d0b7b5a835cc8555b8/lfortran/ast/ast_to_src.py 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 https://gitlab.com/lfortran/lfortran/issues See also my current roadmap/priorities at the bottom of: https://lfortran.org/ https://lfortran.org/
- gus_massa 7y ago
  I suggested intersection format for the code generator part. Also, there is a huge amount of legacy code flying around. Write the fixed form parser as soon as you can. An example of legacy code with linenumbers is: (Extracted from real code, I only changed the variable names.) do 1 i = 1 , n do 1 j = 1 , n if(x(i,j).ne.y(I,j)) print*,x(i,j),y(j,i) 1 continue
  - certik 7y ago
    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 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 https://gitlab.com/lfortran/lfortran/issues/83. Thanks for the feedback!
    - gus_massa 7y ago
      I've also seen weird controlflow using linenumbers, I pick an easy but common one. I don't expect that the program can handle all the cases and produce something sane. But most of the cases I saw are easily fixable with an enddo or endif.

bocklund 7y ago

Almost all the cases under the “How to fix that” heading seem addressed by Julia, but also MATLAB or Python if performance is not an issue. As a PhD student who heavily relies on highly optimized Fortran code and who has spent time translating small Fortran projects to Python+NumPy, I don’t understand why anyone would start a new project in Fortran. The only people I know who write Fortran do it because of legacy code or because that’s the only language they know. Since calling Fortran is fairly well supported for languages used in/designed for science (Python, MATLAB, Julia), I don’t see legacy code being as big a driver.

certik 7y ago
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.