There are several long standing issues with ASR that need refactoring. We will track of all of them here:

High Priority

• Print ASR after every pass #2194
• Refactor StructType #4263
• ASR idea: explicit pointer vs value #4245
• ASR idea: move dimension expressions from Array to Variable #4244
• StructType, UnionType should use the user defined type approach as discussed in ASR: Implement FunctionType node to represent a function signature #1162 (comment)
• ASR: Print => as Associate; use full names for all other nodes also
• Refactor ASRBuilder #3277
• ASR: Rearrange BinOp as BinOp(Add .. .. ) (move the operator to front, like in s-expressions)
• ASR: use ArrayBroadcast, add ArrayBinOp and ArrayAssignment #2160
• ASR passes refactoring #1941
• ASR passes refactoring #416
• ASR: possible other nodes #2196
• Remove using const_cast from ASR passes #4942 rem: const from visitors generated via asdl_cpp.py #4952
• Add Fortran backend, print any ASR (without needing to apply any passes) as Fortran code, figure out how to test it with gfortran; Write Fortran backend for all of ASR, emit readable modern canonical Fortran code: the code will lose some information (such as physical types for arrays, or various casting / dereference nodes) which are only needed for the backends; however each ASR feature will be faithfully lowered to Fortran. This will ensure that ASR stays higher level than Fortran -- for example we should not have assembly instructions as part of ASR.
  • Add Fortran backend #2410
  • Initial ASR to Fortran implementation #2417
• Simplify ASR creation from C++:
  • ASR Builder to allow writing functions in libasr directly in C++ and be almost as simple as in the frontend language: Register Partition in IntrinsicFunction lcompilers/lpython#1673 (comment)
  • Simplify the ASR builder to be more Python/Fortran like (more defaults)
  • Try creating ASR in a similar C++ syntax as the Clojure like output (this would be fully explicit with all members)
• ASR idea: move dimension expressions from Array to Variable #4244
• FunctionType: ASR: Implement FunctionType node to represent a function signature #1162:
  • Initial implementation: Implement FunctionType in ASR #1189
  • Implement procedure(xx) :: yy #1247
  • Implementation of procedure(fn) :: x (I) #1578 (comment)
  • Add a test for calling the procedure(fn) :: f function using keyword arguments like f(a=5) (requires type_declaration)
  • Add a test for procedure pointers: procedure(fn), pointer :: f; f => my_fn; call f(a=5)
  • Do callback arguments using Variable(type_declaration=Function), rather than Function directly (will simplify the LLVM backend)
  • Function param: ASR: Implement FunctionType node to represent a function signature #1162 (comment) / function argument index (function argument Var), initial implementation: Initial FunctionParam implementation #1309
• Struct and Function design #1570
• All types are strictly global, no direct reference to symbol table (possibly with an exception of user defined pure functions); they can thus be reused via pointers; if modification is needed, one must duplicate the type; enforce this and use it when deserializing: provide some machinery to lookup an existing type quickly and get a pointer to it; Using types is thus cheap, just a pointer in each expr node, and so we can use them liberally
• document the previous point, and the types design: Initial FunctionParam implementation #1309 (comment)
• Remove old Fortran runtime library #3034
• ASR intrinsics design improvements #3129
• IntrinsicFunction (math at first):
  • Initial implementation: Port intrinsics to use IntrinsicFunction #1045, Initial implementation of IntrinsicFunction #1371
  • elemental: Handle IntrinsicFunction in array_op pass #1383
  • sin, simplification: Simplify the Instrinsic Function wrapper #1374
  • maxloc: Initial MaxLoc and MinLoc implementation #1328
  • all: initial implementation in Implement all intrinsic function #1283
  • IntrinsicFunctionSqrt, initially implemented in ASR: Add IntrinsicFunctionSqrt #1227
• rename IntrinsicFunctionSqrt to RealSqrt
• Add IntrinsicImpureFunction and IntrinsicImpureSubroutine: Intrinsic function design improvement #1658
• runtime library: right now we use BindC and implement all interfacing with the system using it; we need to rather introduce specific ASR nodes for interfacing the system (such as clock, file IO, Intrinsic math functions, etc.), the runtime library will eventually be just pure Fortran (not calls into C), possibly using some "LFortran builtin" functions to access specific functionality, and we can emulate them for other compilers so that we can compile the runtime library with other compilers as well; the previous point actually might solve this issue
• Get rid of lfortran_intrinsics.c: WASM: Runtime Library lcompilers/lpython#1413 (comment)
• Design of specific backends (GPU, OpenMP, Coarrays, etc.) lcompilers/lpython#1996
• Closures (parent scope variables): Redesign how to handle global/parent scope variables #1059
• handle elemental explicitly by introducing a "map" node that maps the scalar function to an array, similar to ArrayBroadcast ([fortran-primes]: semantic error: mask argument to any must be an array and must not be a scalar #2529 (comment))
• ASR representation of elemental functions #3225
• Improve printing of ASR to be exactly equal to Clojure #4694
• generics: Templates TODO #1199
• Array as a node (just like Pointer)
• pure functions ([WIP] ASR: Add deterministic and side-effect-free flags to Function lcompilers/lpython#1293)
• string formatting nodes
• Improvements for ASR Print node #2543
• ASR: Logical and Physical Types #1601
  • Implement physical types for arrays #1850
  • array as a descriptor vs pointer (possibly annotate this at ASR), fixed by Implement physical types for arrays #1850
• Simplify ASR.asdl #1900
• Location information in separately compiled modules does not work #1870
• Add explicit pointer dereference nodes (will simplify logic in the LLVM backend regarding loading/not loading a value)
• Document Design: why we represent intrinsic functions as "applied" only #2781.

Medium

• How to compile ML code using ASR #3642
• C interop improvements to the C++ backend #533
• Redesigning strings #2257
• Handle invalid code (both syntax errors and semantic errors) with dedicated ASR nodes, so that almost any code can produce an ASR, for language server purposes.
• passing arrays to functions, check dimensions at runtime
• possibly unifying expr/stmt, or creating "ExprStatement" to represent expressions as statements (in Python and interactive Fortran)
• Implement Lambda functions, as expressions, possibly unify with Function (Implement Lambda function #1580)
• ASR hardening
  • harden verify (catch all errors)
  • ASR testing: do randomized exhaustive tests (catch all verify and all backends errors)
  • Figure out a subset of ASR that is complete and add optional ASR passes to lower to this subset; this will enable writing new backends very easily, and together with exhaustive testing we can ensure that these passes + small backend is completely and without bugs, which will harden everything. For performance reasons, our production backends like LLVM should handle a lot more things directly, but we can at least guarantee that the subset works well and is without bugs.

Later

• Lambda: Implement Lambda function #1580
• runtime library: possibly have a runtime library in ASR for common functions; that comes much later, first we'll create pure surface level runtime library, then we'll think if it makes sense to share some of the implementations across frontends. Allow surface level implementation of backend runtime features, see WASM: complex numbers lcompilers/lpython#1519 (comment) for details
• Add symbolics
• shallow/deep copy semantics
• deallocation mechanics
• allocatable life time
• rcp (reference counted pointer), unique_ptr, shared_ptr: Reference counted pointers #5382
• manipulation of ASR at runtime (for macros, etc.), possibly some nodes for fast handling of AST/ASR
• Idea: add our own LLVM compatible API #1905
• ASR pass: lift global variables into function arguments #1906

For LLVM backend issues see: #1302