Fix ASR indexing - 0 based/1 based?

[Smit-create]

Let's take an example of the StringSection node. It was introduced in lpython and now it is also used in lfortran. The current StringSection in the LLVM backend is implemented based on 0-based indexing and so works for lpython but fails for lfortran. We need to have these fixes in ASR so that each front end follows the same indexing in every node.

See the following snippet in python:

def f():
    s: str = "checking"
    r: str = s[1:4]
    print(r)
f()

Works fine:

% lpython b.py
hec
% python b.py
hec

Fortran

program main
    implicit none
    character(len=10) :: b
    b = "checking"
    print *, b(1:4)
end program main

Fails:

% lfortran a.f90 
hec
% gfortran a.f90 -o a.out && ./a.out
 chec

This should also be kept the same for loops etc.

cc @certik @czgdp1807

[certik]

Yes, I think we have an issue for this somewhere. We need to pick either 0 or 1 for these in ASR. For arrays we always include the first index, so there is no problem. For the rest of the nodes I would pick and probably 0, as that makes it easier on the LLVM backend.

[Smit-create]

Okay, I think we should probably go with 1 based indexing everywhere to keep it uniform and probably fix that in lpython?

[certik]

I would pick 0 for the following reasons:

• In Fortran the most indexing is in arrays and arrays can be indexed from any lower bound.
• The only other indexing in Fortran is into strings, and Fortran strength is in arrays, not strings, so any potential slowdown in compilation or perhaps even runtime (not sure) is better than slowing down Python:
• In Python there is indexing into strings, lists, tuples, etc. These are important data structures in Python (and not used in Fortran), so having native indexing seems better
• I think it's easier in the LLVM backend

The only downside is that our future Fortran backend has to fix up string indexing.

If we pick 1, then Fortran is fine, but we have to adjust indexing in Python a lot.