Test failed - added support for int and float

[ronnuriel]

Signed-off-by: Ron Nuriel rnuriel@gsitechnology.com

[czgdp1807]

This works with LPython but not with CPython. CPython throws the following error,

Traceback (most recent call last):
  File "/Users/czgdp1807/lpython_project/lpython/integration_tests/array_01_decl.py", line 12, in <module>
    def accept_int_array(xint: int[:]) -> i64:
TypeError: 'type' object is not subscriptable

So I pushed 8336f96. Using py_float, py_int seems a bit hackish but then the alternative is to not support x: float[:], x: int[:], which makes reduces the significance of x: float use case. Like if users can only declare normal variables and not arrays using floating point annotations then its not worth it to support float annotation. What do you say @certik ?

[czgdp1807]

Is there any other way to achieve this (i.e., make the float[:] work with CPython)?

[rebcabin]

Why not something like Array[int]? int[:] might not be in the spirit of PEP 483.

I general, we should never have something that works in LPython and not in CPython. That's an extension of Python and is a road to perdition! The reverse is ok IMO.

[czgdp1807]

Array[int] makes sense. For multi-dimensional arrays, should it look like, Array[Array[int]]? Plus then we should also support Array[Array[f32]] (similarly for all the ltypes).

[certik]

This is a more complex issue, so I created #1107 where we can discuss it more. In short: Array[int, :, :] can probably be done, but it's quite verbose, so we should first decide if we want to go this route, in addition (or even instead!) of the short i64[:,:] syntax. Also note that int in CPython means arbitrary precision integer, so we should not use it interchangeably with i64. However, float in CPython means f64, so that could be done, for scalars. For arrays of f64, the same issue happens. See #1107 for more discussion.

[certik]

This we should not do, since int means arbitrary precision integer, which we will eventually support in LPython as well, but that is not the same as f64.

[certik]

This is currently not supported in LPython, as we do not allow arbitrary precision integers.

[certik]

To move forward, I would not allow int to mean i64, since we will eventually support arbitrary precision integers, and int can be reserved for that, since that is what it means in CPython.

We could allow float to mean f64, since that is what it means in CPython, but as discussed in #1107, we use the nice syntax f64[:,:] to mean multidimensional arrays, but that is not possible with float. So given this, I would lean towards not allowing float at all, to reduce any kind of confusion why float[:,:] does not work. In #1107 I list a few workarounds that we could do, but none of these are ideal.

Instead, why don't we do the following: if a user writes float, LPython will give a compiler error and suggest to use f64 instead. For int, the compiler should say that arbitrary precision ints are not implemented yet, but you can use i64 or i32 instead.

[certik]

I am marking this as Draft for now. If this becomes ready, just click on "Ready for review".