Original issue: https://gitlab.com/lfortran/lfortran/-/issues/72

Once code is parsed into an ASR, be able to rewrite this ASR into a form that can be understood by other Fortran compilers, and then generate Fortran source code. That will allow to use the latest Fortran features (and even LFortran specific extensions such as the custom
use extension https://gitlab.com/lfortran/lfortran/-/issues/44) with any other Fortran compiler.

This is a similar approach that TypeScript uses, it is able to generate JavaScript that works in all browsers.

Original issue: https://gitlab.com/lfortran/lfortran/-/issues/64

Currently this repository is mirrored at GitHub automatically: https://github.com/lfortran/lfortran

Wiki, issues are all disabled. Unfortunately the GitHub PRs cannot be disabled, so we need to setup a bot that will automatically close any PRs that people might open (despite the repository description that this is a mirror), with a nice informative message to "please send this PR to https://gitlab.com/lfortran/lfortran".

We should try to use https://github.com/dessant/repo-lockdown, which does exactly that.

Original issue: https://gitlab.com/lfortran/lfortran/-/issues/76

One way to do that is to setup a GitLab bot, which listens for a webhook from an MR. It will forward it to a pipeline in a separate repository (it will forward the whole JSON payload to it via the user variables in the pipeline trigger). This separate repository's pipeline will then analyze the JSON, download the MR from lfortran/lfortran, downloads the MR git, and uploads to azure pipelines. This will get Azure pipelines running for each MR automatically.

Finally, it would be nice to set the Azure build status also, and for that we can follow the same approach as in https://gitlab.com/lfortran/lfortran/-/issues/75.

Original issue: https://gitlab.com/lfortran/lfortran/-/issues/70

Gradually we will port to C++ for speed and robustness. We will keep the same (or very similar) Python API, so that code that is written on top of the current LFortran does not have to change much (and also it allows us to make this move gradually), but the underlying compiler will eventually be in pure C++ as a standalone binary. Then we can also have wrappers to other languages.

Original issue: https://gitlab.com/lfortran/lfortran/-/issues/34

Original issue: https://gitlab.com/lfortran/lfortran/-/issues/83

Here is an example from here:

        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

Original issue: https://gitlab.com/lfortran/lfortran/-/issues/32

Original issue: https://gitlab.com/lfortran/lfortran/-/issues/24

Original issue: https://gitlab.com/lfortran/lfortran/-/issues/75

Appveyor runs on forks already, but it is not allowed to set the build status. This could be achieved by having a job that finds the correct AppVeyor URL and periodically keeps checking the status, and then the job itself either succeeds or fails based on the AppVeyor status.

Original issue: https://gitlab.com/lfortran/lfortran/-/issues/68

So that lfortran and fortran_kernel can be conda installed and things will just work.

Original issue: https://gitlab.com/lfortran/lfortran/-/issues/59

Or perhaps pprint_ast().

Original issue: https://gitlab.com/lfortran/lfortran/-/issues/22

Add proper testing using the Table 7.2 on page 140 in http://www.j3-fortran.org/doc/year/10/10-007.pdf.

Fix https://gitlab.com/lfortran/lfortran/-/issues/90 as part of this issue.

Original issue: https://gitlab.com/lfortran/lfortran/-/issues/58

Right now only a subset of Fortran is supported. This issue is to implement the full Fortran 2018 standard.

Original issue: https://gitlab.com/lfortran/lfortran/-/issues/101

List additional fields in: https://lfortran.github.io/tarballs/data.json that can then be used to show useful information at https://lfortran.org/download/.

Additional fields:

• filename
• file size

Original issue: https://gitlab.com/lfortran/lfortran/-/issues/45

Currently we depend on either gcc and the standard libc, or with the --ld-musl flag on ld and musl. It would be nice to be able to compile executables without depending on any external package.

To do so, we have to link the .o files ourselves (see also numba/llvmlite#311). One can use link_in() in llvmlite to link the LLVM modules together, then we have just one .o file. Then we need to convert it into an executable.

1. The first step is to do it without linking against any other library (such as libc). Here are some initial pointers how to do get started on that:
   https://blogs.oracle.com/linux/hello-from-a-libc-free-world-part-1-v2
   https://blogs.oracle.com/linux/hello-from-a-libc-free-world-part-2-v2
   http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html
   https://stackoverflow.com/a/2548601/479532

2. The second step is to figure out how to link in other libraries (such as libc and others).

The compiler will have several options:

a) use gcc to link (already implemented as default)
b) use ld to link (already implemented as --ld-musl)
c) or our own linking (to be implemented, see above)

The advantage of a) is that it works on all platforms easily, but one depends on gcc. The advantage of b) is that it doesn't require gcc, but it is more platform dependent. The advantage of c) is that it doesn't depend on any external package, and so the compiler is completely self-contained/self-sufficient to produce executables, but we have to implement the functionality of a linker, which is specific to each platform.

I think a good plan for c) is to start with a simple proof of concept that works, and then keep improving it. It doesn't have to be feature complete right away, as one can use a) or b) for that.

Original issue: https://gitlab.com/lfortran/lfortran/-/issues/51

Such arrays are implemented by simply passing a pointer to the data (no array descriptor as in https://gitlab.com/lfortran/lfortran/-/issues/50 is needed) and the size/shape of such arrays is either known at compile time or at function invocation time.

Initial 1D implementation has been implemented in https://gitlab.com/lfortran/lfortran/-/merge_requests/123.

TODO:

• Allow to infer the size of the array from a function argument (e.g., integer, intent(in) :: a(n)).
• Implement multidimensional array support
• Fix all corner cases

Explicit-shape arrays are easy to implement, and after this issue is fixed, it will allow people to start writing numerical algorithms using LFortran.

The assumed-shape arrays (https://gitlab.com/lfortran/lfortran/-/issues/50) are more powerful, but also more difficult to implement, and so they will be implemented after this issue is fixed.

Original issue: https://gitlab.com/lfortran/lfortran/-/issues/48

It should import C header files using the syntax from https://gitlab.com/lfortran/lfortran/-/issues/44:

use, external(c) :: math, only: sin
print *, sin(5._dp)

This will parse the math.h header file using clang (we just link with libclang) and automatically create an implicit Fortran wrapper. As an option, it will generate the iso_c_binding wrapper for other Fortran compilers that don't support the use, external(...) LFortran extension.

Here is how Zig does it:

https://ziglang.org/documentation/master/#Import-from-C-Header-File

Original issue: https://gitlab.com/lfortran/lfortran/-/issues/104

The Open Fortran Parser is based on ANTLR, just like the current Fortran parser in LFortran.
Maybe it can serve as a foundation to build LFortran upon, since it already implements the Fortran 2008 standard. Or at least it could be used temporarily while LFortran catches up with it.

I hope it can help save time and effort, which are better spent implementing the cool features that set LFortran apart from other compilers.

Original issue: https://gitlab.com/lfortran/lfortran/-/issues/41

Or "core values". I've done it partially here: https://www.fortran90.org/src/faq.html#what-is-the-advantage-of-using-fortran-as-opposed-to-for-example-c-c

But I think it can be updated. Here is a nice talk about doing the same "exercise" for C, C++ and JavaScript:

https://www.youtube.com/watch?v=cJP7SSLjvSI

Original issue: https://gitlab.com/lfortran/lfortran/-/issues/82

There is a lot of legacy code around and it would be very useful to be able to parse any Fortran code that people are using, including fixed-form.

Technically, this will probably have to be a separate parser, but probably the AST and definitely the ASR level will stay the same.

Original issue: https://gitlab.com/lfortran/lfortran/-/issues/28

http://blog.leahhanson.us/post/julia/julia-introspects.html

Implement an equivalent of:

• Layer 1: : (our AST) --- we'll continue using parse, just like in Python
• Layer 2: code_lowered (AST where for loops are converted to while loops, Julia also converts if/for and other things)
• Layer 3: code_typed (our type annotated AST tree)
• Layer 4: code_llvm (the LLVM IR code)
• Layer 5: code_native (assembly code)

LFort does exactly the same thing, but we seem to do code_typed before code_lowered.

Original issue: https://gitlab.com/lfortran/lfortran/-/issues/84

This is an idea to consider:

The . is a lot more readable, consider os.path.join() vs. os%path%join(). The reason it's more readable is because the . has more vertical space, and thus the words are visually more divided, while the % character is filling up all the space, and thus visually it is much harder to immediately see where one word ends and another begins.

Besides . being more readable, it is also way more common, e.g. in Python, C++, Julia and many other languages.

And Intel Fortran actually seems to support it in some cases.

It makes the parsing ambiguous, since a.not.b can be an operator .not., or derived type access. In addition, Fortran allows to have user defined operators, so any word of the type .something. can be an operator. However, there might be a way to parse things properly and to disambiguate this.

For example one way to do that would be that a.not.b would mean .not. as an operator. One should not use derived types with names like not. Regarding user defined operators, I would say user defined operators will take precedence, and so if one imports a user defined operator, say .path., then os.path.join() will mean .path. as an operator. One would need to use % in such a case then. This will be very rare, so shouldn't be a problem.

Original issue: https://gitlab.com/lfortran/lfortran/-/issues/26

Original issue: https://gitlab.com/lfortran/lfortran/-/issues/56

Right now LFortran has preliminary support for GFortran (loading module files, linking against object files compiled by GFortran). This issue is to add similar support for other Fortran compilers such as Intel, NAG and others.

Original issue: https://gitlab.com/lfortran/lfortran/-/issues/97

This has been requested several times.

1. The first step would be to add code that takes an ASR of some Fortran function and returns the derivative as an ASR.

2. Then one can easily write a Python script that will retrieve a Fortran function from a module, differentiates and generates Fortran code in a new module.

3. Further improvement can be to have something like pragmas, something like:

   !pragma lfortran autodiff(pow_diff)
   real(dp) function pow(x, a)
   pow = x**a
   end function

   which would call an autodiff function implemented in step 1. above, and "insert" the generated function in the current module as pod_diff function. This would be a general mechanism how to create "macros" or anything else we want. One would simply implement any such custom functionality, say, using the Python API of LFortran.

Another option to explore would be to add a new type, for example as an LFortran extension implemented using the code from 1. I don't know if that makes sense or not, I feel the option 3. might be the best way to integrate this with Fortran.

We can get inspired, e.g., by the Zygote module in Julia.

Original issue: https://gitlab.com/lfortran/lfortran/-/issues/100

Currently the github mirror only runs on master, but not tags. So the tags only get pushed when the master gets updated after that.

Original issue: https://gitlab.com/lfortran/lfortran/-/issues/42

The general idea is to follow the Roslyn design:

https://github.com/dotnet/roslyn/wiki/Roslyn%20Overview

One can play with the Roslyn AST viewer here:

https://sharplab.io/

The problem is that it seems the Roslyn AST is not as simple as our LFortran AST. For example Roslyn has all the tokens like } and ; in the AST tree. But those are not needed for the rest of the compiler, because they do not convey any semantic information.

So we decided to first design LFortran's AST and ASR to be as simple and abstract as possible. We are pretty close with the design. It is important that the design is not influenced by this round-trip requirement, but rather by the requirement that AST and ASR is simple, because that will simplify the rest of LFortran as well as all the other tools that people will write on top.

Next step is to figure out how to add all the optional nodes like white space, ;, end if and other tokens, so that the original source code can be exactly reproduced from AST, and perhaps even from ASR (that's even more complicated than from AST, because ASR does not have any declaration nodes).

Another open question is whether these optional white space nodes should always be generated, or only when the given (refactoring) tool requires it.

One should note that we can use the current AST to do formatting, and if the source code is always formatted the way LFortran does it, then we can use LFortran to do refactorings. It's just that it would be very nice to have a tool that can refactor a code base that is not already formatted using LFortran, exactly preserving the original formatting.

Original issue: https://gitlab.com/lfortran/lfortran/-/issues/46

Create a set of Jupyter notebooks with showing some very simple numerical algorithms, with plotting.

The hope is to attract some very first users, or enthusiasts to help out.

Original issue: https://gitlab.com/lfortran/lfortran/-/issues/81

Just like xeus-cling does:

https://github.com/QuantStack/xeus-cling

Original issue: https://gitlab.com/lfortran/lfortran/-/issues/60

This does not get parsed properly:

from lfortran.ast import src_to_ast, print_tree
from lfortran.ast.ast_to_src import ast_to_src
src = """\
integer function f(a)
integer, intent(in) :: a
f = 2*a
end function
"""
ast = src_to_ast(src, translation_unit=False)

because the following:

from lfortran.semantic.ast_to_asr import ast_to_asr
print(ast_to_asr(ast))

prints:

function f(a)
integer, intent(in) :: a
f = (2) * (a)
end function

and ast_to_asr() gives an exception.

Original issue: https://gitlab.com/lfortran/lfortran/-/issues/57

Parallelize do concurrent on both CPU and GPU, with similar features as Kokkos (do side-by-side comparisons with Kokkos).

Support GPUs using a similar approach as Numba.

Original issue: https://gitlab.com/lfortran/lfortran/-/issues/105

It is designed for mixing languages. It supports the JVM, Python, R, Ruby and LLVM. Integrating with it would open the door to a vast amount of scientific codes.

Original issue: https://gitlab.com/lfortran/lfortran/-/issues/92

Multiple people asked us to document what subset is currently supported. I think the best way to do that would be to use Jupyter notebooks to document and show examples of what works. The documentation would look similarly to https://docs.lfortran.org/developer_tutorial/, which is also powered by a Jupyter notebook.

For each Fortran feature, there will be 3 parts: AST, ASR and LLVM code / interactive usage. The notebooks should probably be Fortran notebooks, and
one would use %%show_ast, %%show_asr and just regular compilation.

Something like this:

%%show_ast
integer :: i
i = 5 + 1
i

and

%%show_asr
integer :: i
i = 5 + 1

and

integer :: i
i = 5 + 1
i

Some features will only have an AST, but ASR and LLVM doesn't work yet, some features will have AST and ASR, and finally some features will have all three AST, ASR and LLVM.

That way when we first implement some feature in the parser, we can add it in as AST only. Then we implement semantics, so we add the ASR section. Finally, when we implement it in the code generation backend, we add the last section.

Original issue: https://gitlab.com/lfortran/lfortran/-/issues/8

Propagate them into the AST and write tests.

Original issue: https://gitlab.com/lfortran/lfortran/-/issues/78

Variable should only be in the symbol table, but expr should have VariableRef(Variable var). That way it is easy to distinguish, e.g. while pretty printing, if we are printing a variable reference, or a variable definition in the symbol table.

Original issue: https://gitlab.com/lfortran/lfortran/-/issues/90

When I try to declare a string (character with length), like this:

./lfort
> character(len=5) :: my_string

I get the following error message:

Syntax Error:1:17: mismatched input '::' expecting {<EOF>, ';', NEWLINE}
character(len=5) :: my_string

And if I try to declare a single letter variable like this:

./lfort
> character :: letter

LFortran crashes with the following stack trace:

Traceback (most recent call last):
  File "./lfort", line 6, in <module>
    main()
  File "/home/steve/Programs/lfortran/lfortran/cli.py", line 82, in main
    main(verbose=verbose)
  File "/home/steve/Programs/lfortran/lfortran/prompt.py", line 122, in main
    handle_input(engine, fortran_evaluator, text, verbose)
  File "/home/steve/Programs/lfortran/lfortran/prompt.py", line 63, in handle_input
    mod = evaluator.llvm_code_generation(ast_tree)
  File "/home/steve/Programs/lfortran/lfortran/codegen/evaluator.py", line 91, in llvm_code_generation
    self.symbol_table_visitor._global_scope))
  File "/home/steve/Programs/lfortran/lfortran/codegen/gen.py", line 678, in codegen
    v.codegen(tree)
  File "/home/steve/Programs/lfortran/lfortran/codegen/gen.py", line 226, in codegen
    self.do_global_vars()
  File "/home/steve/Programs/lfortran/lfortran/codegen/gen.py", line 267, in do_global_vars
    var_type = self.types[type_f]
KeyError: Character()

Original issue: https://gitlab.com/lfortran/lfortran/-/issues/12

Implement a "Language Service", which is a server exposing a JSON based API that accepts user cursor movement and each character changes. It brings back, e.g., a list of members for the editor to show.

How it works:

• Each source file gets compiled to AST.
  • If a source file does not change, the AST does not change. AST is immutable. Type annotations are kept in a separate hash table.
  • If a source file changes at a place, only that node at the given place and all parent nodes must change (in the direct line to the root), but all other nodes in the file can be reused and hooked in. This saves time to reconstruct the AST
• The AST is thus always available and ready.
• Type annotations must be redone, since some base type can change in a file, and all modules that depend on it can change their type annotations too. The AST however does not change. In Fortran, a given module can be fully compiled if just the symbol table is known. So given a symbol table, one must redo type annotations for all AST trees of all modules.
• The type annotations are slow in general, so they work on the "pull" basis --- for a given symbol, one can figure out a type by going over the parents, and the rest of types are not computed.
• For a source file change, the mentality is to "start over". The type annotations are erased (but perhaps can be reused in some fashion to build the new annotations). The AST is only changed in one file at a time, and one can greatly reuse the AST tree in there too, as described above.

Typescript does it:

https://github.com/Microsoft/TypeScript/wiki/Architectural-Overview

C# also has it:

https://github.com/dotnet/roslyn
https://msdn.microsoft.com/en-us/magazine/dn879356
https://github.com/dotnet/roslyn/wiki/Syntax%20Visualizer

Clang has it: https://github.com/llvm-mirror/clang-tools-extra/tree/master/clangd

There seems to be a standard now: https://en.wikipedia.org/wiki/Language_Server_Protocol, and it is supported, e.g., by https://en.wikipedia.org/wiki/Visual_Studio_Code.

Original issue: https://gitlab.com/lfortran/lfortran/-/issues/50

Here is a nice explanation how gfortran does it:

https://thinkingeek.com/2017/01/14/gfortran-array-descriptor/

struct descriptor_dimension
{
  ptrdiff_t stride;
  ptrdiff_t lower_bound;
  ptrdiff_t upper_bound;
};
 
template <int Rank, typename Type>
struct descriptor {
  Type *base_addr;
  size_t offset;
  ptrdiff_t dtype;
  descriptor_dimension dim[Rank];
};

MR https://gitlab.com/lfortran/lfortran/-/merge_requests/125 shows how to work with structures in LLVM.

MR https://gitlab.com/lfortran/lfortran/-/merge_requests/126 shows how to use GFortran's assumed-shape arrays from another Fortran or C++ compiler.

Original issue: https://gitlab.com/lfortran/lfortran/-/issues/73

It will work similarly to Python: one can have code like the following in Fortran comments:

! >>> use utils, only: f
! >>> f(5)
! 10

And it will discover such blocks and execute them and check that the result (10 in the example above) agrees with the command (f(5)).

This will allow Fortran code to be documented with examples of usage (and tested to ensure it actually works), just like in Python.

Original issue: https://gitlab.com/lfortran/lfortran/-/issues/87

It could be really illuminating to compile statistics for a large sampling of production codes written in modern Fortran and see which features are actually used most, and which used least if at all. Things like:

• OOP stuff
• operator overloading
• derived types
• arrays (what type, ranks, etc.)
• type of do loops (how many nesting, etc.)
  ...

Such statistics could be most enlightening and helpful for the Fortran Standards Committee to establish the most genuinely helpful priorities going forward.

LFortran should have an option to produce such a statistics for the given code.

Original issue: https://gitlab.com/lfortran/lfortran/-/issues/29

Here are some nice features that lfort can have that other Fortran compilers don't have:

• nice stacktraces
• safe mode (https://gitlab.com/lfortran/lfortran/-/issues/369) --- where everything is checked, including pointers (keeping track of who points at target variables and when they go out of scope, mark pointers as dangling, and if dereferenced, error out with a nice stacktrace: https://gitlab.com/lfortran/lfortran/-/issues/366), arrays (https://gitlab.com/lfortran/lfortran/-/issues/367), everything. If a code compiles and then segfaults or has undefined behavior, it's a bug in lfortran. Once code never gives a stacktrace for any user input, then it can be run with all optimizations on, or compiled with other compilers.
• all optimizations on by default (just like ifort)
• better than gfortran one at least some benchmarks
• compile all modern codes
• arbitrary precision real numbers
• Arb real numbers
• exact real numbers (using symengine to build up an exact numerical expression) --- so things like 1+pi+sin(3) would keep a symengine expression internally.
• provide optional error propagation for double precision and print lost digits in red or gray.
• The previous point is essentially an interval arithmetic (https://pdfs.semanticscholar.org/609c/b8e89c7ad0bbfdc6bc79eb3861ccf806122f.pdf), but changed to value+radius, so that it Debug mode you turn on radius, but in release mode you turn off radius, and obtain fast (and identical) results. See also: http://fab.cba.mit.edu/classes/S62.12/docs/Hickey_interval.pdf
• Provide checks for Fortran school of thought --- randomize operation order in loops, rewrite expressions in random ways, according to the rules of the Fortran school. If the code is written using the rules, it should always work even with randomization.
• Julia like macros ([@ assert](https://gitlab.com/assert) x == 1), implemented in Fortran by implementing a "function", except it would be called a macro, not a function. This means easy access of AST from Fortran (and the required datastructures), and probably the :() and : operators.
• Converting functions to subroutines, for faster returning of arrays (https://gitlab.com/lfortran/lfortran/-/issues/384)
• Incremental compilation (in Jupyter notebook), JIT compilation, behaving like a scripting language, REPL prompt, this would mean relaxing the order of statements, so that one can define a subroutine, and statements before/after.
• Expose the compiler as a library, for IDE integration, etc. (https://gitlab.com/lfortran/lfortran/-/issues/12), also with nice Python interface for experimenting, writing new applications (say, for spitting out C header files)
• Automatic wrapping into Python/NumPy, so that one can call subroutines from Python without any extra work from the user.
• Save the AST and semantic analysis (and all dependency modules with full paths) into the *.mod files and create a similar file for programs. One compiles a bigger project using any build system (say, cmake). lfort generates these *.mod files correctly. Then write external tools that can read these (one points to the main program *.mod file and it has links to all the others) and can produce say C header files, or provide proper symbols for IDEs (ctags), or anything else one would like to do with the code.
• Hook into loopy and other array optimizing libraries.
• Automatic calling from Python (no need to write any iso_c_binding C / Cython wrappers by hand) and other languages.

Original issue: https://gitlab.com/lfortran/lfortran/-/issues/43

https://gitlab.com/lfortran/lfortran/-/jobs/111812682

...
removing 'lfortran-83943a0' (and everything under it)
/home/swuser/conda_root/lib/python3.6/site-packages/setuptools/dist.py:351: UserWarning: Normalizing '083943a' to '83943a0'
  normalized_version,
...
+ cp dist/lfortran-083943a.tar.gz /home/swuser/repos/lfortran-deploy
cp: cannot stat 'dist/lfortran-083943a.tar.gz': No such file or directory

Essentially the hash 083943a gets changed to 83943a0, but the script still thinks the version is 083943a and so it fails.

Original issue: https://gitlab.com/lfortran/lfortran/-/issues/89

For pages that are generated from a Jupyter notebook, the "Edit on GitLab" link is broken, because the corresponding MD file actually not saved in the repository. We could use mknotebooks after this issue is fixed.

We disabled the link for now (in https://gitlab.com/lfortran/lfortran/-/merge_requests/192), and after we fix this, we can enable it again.

Original issue: https://gitlab.com/lfortran/lfortran/-/issues/71

There are two fundamental projects:

• Use LFortran for SymPy's code generation. SymPy will target the LFortran's ASR, and LFortran can both generate Fortran code from it, as well as compile directly (whether JIT or to executable).

• Use LFortran to parse Fortran code into ASR, then extract all expressions in each subroutine and convert them to SymPy (where it makes sense). This project allows then to hookup into modules such as Herbie, or do many other kinds of analysis using SymPy.

Here are SymPy GSoC 2019 project ideas regarding this: https://github.com/sympy/sympy/wiki/GSoC-2019-Ideas#lfortran-sympy-project-ideas

Original issue: https://gitlab.com/lfortran/lfortran/-/issues/55

Currently the types are not checked, and also they are not part of the "fields". This is an omission.

Original issue: https://gitlab.com/lfortran/lfortran/-/issues/79

Currently we upload binary releases to Dropbox in https://gitlab.com/lfortran/packages/lfortran-recipe, however Dropbox has a 2GB limit total.

We should instead upload them to GitHub, which doesn't have a limit on the number of binary files uploaded to a Release (each file must be under 2GB however). Our CI at lfortran-recipe will upload automatically, we can use this method from PyGitHub to do so.

I would like to upload the binary releases for every commit. Alternatively, we can just have some tag "latest" and keep overriding the binaries there with the latest commit. That would save some space if needed.

Also, there should be a nice webpage that provides the links, and tagged releases should have a section with links at https://lfortran.org/download/.

Original issue: https://gitlab.com/lfortran/lfortran/-/issues/65

Right now we always use Conda. We need to add a test that things can be installed without Conda, using pip.

Original issue: https://gitlab.com/lfortran/lfortran/-/issues/33

I am leaning to do -O0 by default, just like gcc/clang, to be compatible. And -Ofast will enable all optimizations including -ffast-math.

Original issue: https://gitlab.com/lfortran/lfortran/-/issues/44

Use the approach explained here: https://eli.thegreenplace.net/2015/calling-back-into-python-from-llvmlite-jited-code/ to bridge with Python.

The syntax from Fortran side should be (thanks to @ nncarlson for the suggestion):

use, external(python) :: numpy, only: sin
print *, sin(5)

For plotting, without lfortran knowing anything about matplotlib:

use, external(python) :: pylab, only: plot, savefig
call plot([1, 2, 3], [1, 2, 1])
call savefig("someplot.pdf")

For nested Python modules, we need some syntax to do that, here are three suggestions:

use, external(python) :: numpy.linalg, only: cholesky
use, external(python) :: numpy:linalg, only: cholesky
use, external(python) :: numpy%linalg, only: cholesky

Essentially this boils down to allowing Fortran modules to be nested (by convincing the Fortran committee to), and then reuse the syntax for that (whatever syntax the committee agrees upon).

Calling C++ could be something along the lines:

use, external(cpp) :: xtensor, only: sin

Calling C would be (see https://gitlab.com/lfortran/lfortran/-/issues/48 for details):

use, external(c) :: math, only: sin
print *, sin(5._dp)

Original issue: https://gitlab.com/lfortran/lfortran/-/issues/52

One can compile production code with gfortran, which produces gfortran specific mod files. Those can already be parsed by lfortran.adapters.gfortran.mod, which creates an equivalent ASR representation of the module.

Now we just need to allow them to be used "out of the box" with LFortran simply by "using" them:

use some_mod, only: some_fun
call some_fun(5)

where some_mod was compiled with gfortran.

Later we can add support for other Fortran compilers also (https://gitlab.com/lfortran/lfortran/-/issues/56).

This will allow to use LFortran with production codes right away. Simple functions in a module would work, and for more complex functionality not yet implemented by LFortran all one has to do is to write a simple module, compile with gfortran, and then use in LFortran interactively.

Note: a related project is gfort2py, which down the road can hopefully use lfortran.adapters.gfortran.mod so that they do not have to maintain their own parser.