“Those who plan do better than those who do not plan even though they rarely stick to their plan.“ ― Winston Churchill

Welcome everyone, this is your host Nikhil Maan aka Sc0rpi0n101 and this week I have some good news for you all. We have got a few plans to get the progress of the project rolling as the second evaluation approaches. The meeting also took place this week, so, after waiting for so long, we have some good insights from the meeting this time.

The Fortran Parser

parser devil

We will be talking about the Parser that uses the codegen AST as that’s the parser we will be using for the project in the future. The parser currently fully supports function and variable definitions. What it lacks is support for assignments and binary operations that were present in the parser that used the python AST. So, the first thing to do will be to add support for these features. Other than that, tests need to be written for the parser as the pull request currently has no tests.

I have also changed the API for the parser and handling the expressions. The expressions are now handled by a class SymPyExpression, which will handle the complete API for parsing. It will be used to get expressions from source code and store it. It can also be used to convert the expressions into the source code for another language using SymPy’s code printers.

How I plan to Complete the Parser?


The first problem and the easier one is to write tests, which will be handled easily as most of the tests for the supported features are present in the pull request with the parser using python AST. The tests will only require a little modification to be useful for the current parser.

The next one is to provide support for assignments and binary operations when Binary Operations are not supported in SymPy’s codegen AST. One way to solve that is to create AST nodes for these features, but that’s a job for later. Currently, the best solution is to manage the transformation function such that they can generate the results in the form currently supported by the AST.


The AST might not have Binary operation nodes, but the Assignment node still supports but it supports the Add and Mul operations from the core module of sympy which can be called using Symbol. So, the plan is to implement binary operations using SymPy’s core operations.

LFortran Documentation


This week, I have also submitted a merge request in the LFortran Gitlab repository with a revision to the LFortran Documentation. The revision includes adding a new section to keep track of the features currently supported by LFortran ad which features are still under development. This can help both the developers and the end-users to track which features can be used, and which features they can expect bugs in.

There is still some more work that can be done regarding documentation improvement. The docstrings for the implementations in LFortran can further be improved. There are a few functions that can help users after being documented and some which can help the developers understand the working better. Both of these types of changes will require different styles and level of details according to the desired user. So, this is going to be an exciting job to manage the documentation to handle the needs of two different types of audience.

The Meeting


The fabled Meeting finally happened. The last 2 week’s blogs have been without any insights from meeting. But don’t worry, you won’t have to wait for another week. The meeting did take place this week.

The meeting was originally scheduled on Tuesday, but I couldn’t make it on the day. So, it had to be rescheduled the next day. There was no meeting last week too, so, there was some catching up to do regarding the progress of the project and what work had been done and what was still left.

tuesday meeting

After getting on track with the work, the problems with Travis builds were discussed. It was decided that the Fortran parser PR will be completed and merged first and LFortran would be packaged for conda-forge. Any features left in the Fortran parser will be implemented while LFortran is getting packaged.

Then there was a discussion regarding the documentation and how should documentation be handled for different kind of users and working on the LFortran ASR. Some ideas regarding the API and superclass for the parsers were also discussed. The meeting ended with discussing the todos and plan for the next week.

A summary of the plan:

  • Write tests for the parser
  • Complete any work that’s left in the parser
  • get LFortran in the conda-forge and get the Travis builds running
  • Make sure the PR is ready to be merged by the time the build pass.

Thank you for stopping by and Subscribe to the blog if you don’t want to miss any important updates