GitLab

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

• nice stacktraces
• safe mode (#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: #366), arrays (#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 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 (#384 (closed))
• 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. (#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.