Feature Request: Some small improvements for AST/ASR window

[aerosayan]

Hello,

I'm trying to develop a language that compiles down to Fortran 2008, and I found the AST/ASR output in LFortran's playground website to be useful.

Specifically I like that instead of always reading the language standard's EBNF grammar, we can see how the code is parsed and the AST is produced for valid Fortran code.

As a side note, I was surprised to see that the comments are not ignored, and instead kept as TriviaNodes in the AST.

Thanks for creating the "copy output" button, because that would probably be enough for me, as I can copy the text, and process it elsewhere.

However, if you think it would be useful for others, and not be a problem to develop, I may humbly request some small improvements.

I understand that the LFortran team would be busy, and this is not a priority feature, so maybe it could be a good task for first time contributors, so they can develop something that's helpful, but somewhat less challenging.

Requested features:

• Feature to make the output window big, on demand.
• Feature to control the tab/indentation of the AST/ASR output
• Feature to control how the S-Expressions are shown. Currently we have to scroll a lot, and while that's okay, a more compact view maybe better for some.
• Feature to hide/show the actual code along with the AST/ASR, so we can directly see which code is being translated to some AST/ASR node.
• Feature to click some key on our actual code on the left window, and it taking us directly to the AST/ASR node in the output window.

Thanks.

[certik]

Those are great suggestions, thanks @aerosayan !

What language are you developing?

[aerosayan]

Thanks @certik !

Well, I'm developing a scientific language similar to Fortran/Matlab/Julia, but with more emphasis on increasing the productivity of the user, instead of solely focusing on the performance of the code.

Since the code will be compiled down to Fortran 2008, the performance will be automatically inherited from its predecessor, Fortran.

To be more specific about how to increase productivity of the user, my view is that we should simplify the syntax ,make it more organic like C/C++, and allow generic template based data-structures and methods to be easy to use like in C++.

I decided to do this, because I was dissatisfied with C++ due to its complexity, and thought it would be better if there was a language which was somewhat useful as C++, but as performant as Fortran.

More emphasis is also being laid on safety, and correctness of code, so all values will be constant by default,and can only be made variable with the var keyword. This idea is inherited from Rust, and has proven to be good for reducing bugs.

Most of the reserved keywords are 3 character long, and easy to type. We end most statements with semicolon so the code can be represented as a single stream of tokens, with no need for EOL tokens, or line continuation markers. It also allows the code to be valid even if mangled by the user for some reason, and would allow automatic code formatters, and LSPs to format and lint badly written/tabbed/indented code.

In the end, the code syntax will look like this ...

Currently I'm developing the parser, and the compiler can parse function statements, multiple function argument lists, different return types, and nested generic template lists like this ...

I'm developing the compiler in OCaml, and more work is needed to be done ...

[certik]

Excellent, thanks for the explanation. You might also be interested in our other frontends, such as LPython. Simpler syntax (subset of Python), but the same (LFortran) performance. You can generate Fortran from your language, or you could consider targeting our ASR directly. We are developing an ASR->modern Fortran backend, so you would still be able to print Fortran (to be compiled with other compilers) if needed. As you develop your compiler more, if you want to collaborate on the internals at the ASR level, definitely let us know.

[aerosayan]

@certik wow, LPython looks really cool!

Just saw one of your videos on YouTube on the architecture of LPython and that seems extremely useful.

I personally want to compile directly to Fortran and not depend of LLVM, because I want the portability of Fortran, and I want someone to just write the code, and be sure that it will compile on any modern Fortran compiler.

I wanted to use Fortran 95, but the major limitation is the max function length being only 31 characters in Fortran 95.

At least in Fortran 2008 we have 63 characters, and that will allow me to at least use MD5 hash of the function signature to create unique function names. This is necessary to support generic templates, function overloading etc.

Then while generating the Fortran code, I will just use the symbol renaming technique with => to reduce the long function names to something small, so we don't go over the maximum number of line continuations easily.

Fortran is a challenging target as a compiler backend, but I'm making progress.

[certik]

That sounds good. I think most Fortran compilers have some options to handle long names, long lines and many continuation lines. So even though the standard might be limiting, it shouldn't be a problem in practice.