core: Generalize ExprKind::Slice and Constant::Ellipsis. #486

New Issue

lyken · 2024-08-09T17:04:05+08:00

lyken commented

2024-08-09 17:04:05 +08:00

In Inferencer and CodeGenerator, many implementations directly pattern match on expressions to check if they are ExprKind::Slice/Constant::Ellipsis to do work.

However, ExprKind::Slice/Constant::Ellipsis themselves could have well-defined types.

>>> type(...)
<class 'ellipsis'>
>>> type(slice(1, None, 2))
<class 'slice'>

At the moment, nac3core has hiccups in certain areas:

Unifier.is_concrete does not have a defined way to detect ..., and the type concreteness check under Inferencer::check_expr right now does a direct pattern match on the expression itself to look out for Constant::Ellipsis. This makes expressions like my_ndarray[1, ..., 2::] impossible without forcing the ... in the middle to have a bogus concrete type (like type ()).
There is no way to do things like:

my_slice = slice(1, None, 2) # `slice` is not a thing, `slice` type is also not a thing.
print_list(my_list[my_slice]) # `Inferencer` and `CodeGenerator` does not understand `[my_slice]`, it is not an `ExprKind::Slice`.

Consider adding builtin types slice (+ a slice LLVM struct type) and ellipsis, so implementations can check on typechecker types and fix the issues above/allow for future expansions. This may also drastically beautify some implementations in CodeGenerator and Inferencer.

Though this is not a priority now.

In `Inferencer` and `CodeGenerator`, many implementations directly pattern match on expressions to check if they are `ExprKind::Slice`/`Constant::Ellipsis` to do work. However, `ExprKind::Slice`/`Constant::Ellipsis` themselves could have well-defined types. ```python >>> type(...) <class 'ellipsis'> >>> type(slice(1, None, 2)) <class 'slice'> ``` At the moment, `nac3core` has hiccups in certain areas: 1) `Unifier.is_concrete` does not have a defined way to detect `...`, and the type concreteness check under `Inferencer::check_expr` right now does a direct pattern match on the expression itself to look out for `Constant::Ellipsis`. This makes expressions like `my_ndarray[1, ..., 2::]` impossible without forcing the `...` in the middle to have a bogus concrete type (like type `()`). 2) There is no way to do things like: ```python my_slice = slice(1, None, 2) # `slice` is not a thing, `slice` type is also not a thing. print_list(my_list[my_slice]) # `Inferencer` and `CodeGenerator` does not understand `[my_slice]`, it is not an `ExprKind::Slice`. ``` Consider adding builtin types `slice` (+ a `slice` LLVM struct type) and `ellipsis`, so implementations can check on typechecker types and fix the issues above/allow for future expansions. This may also drastically beautify some implementations in `CodeGenerator` and `Inferencer`. Though this is not a priority now.

lyken added the

low-priority

label 2024-08-09 17:04:05 +08:00

lyken changed title from ~~core: don't treat `ExprKind::Slice` and `Constant::Ellipsis` exprs/values specially.~~ to core: Generalize `ExprKind::Slice` and `Constant::Ellipsis`.

2024-08-09 17:24:17 +08:00

lyken referenced this issue from a commit

2024-08-21 16:39:34 +08:00

core/ndstrides: implement ndarray indexing

lyken referenced this issue from a commit

2024-08-21 23:27:26 +08:00

core/ndstrides: implement ndarray indexing

lyken referenced this issue from a commit

2024-08-22 10:08:34 +08:00

core/ndstrides: implement ndarray indexing

lyken referenced this issue from a commit

2024-08-22 16:28:28 +08:00