ilist dialect should use list as a sugar

[Roger-luo]

currently we use IList | list in the statement wrappers to make linter happy, however, when working with larger codebase, one may declare a function as following

def foo(xs: IList): ...

however, when calling this method using a syntax sugar [..]

def main():
    foo([1, 2, 3])

the linter will not be happy about it. I think there are two options here:

1. we just also accept list in type annotation but treat it as IList[T, Any]
2. ban all list syntax sugar

cc: @kaihsin @weinbe58

[kaihsin]

We could do something like this:

1. rename IList class to IListRuntime, since user does not directly using this runtime class anyway.
2. make IList as TypeAlias.

from typing import TypeVar
from typing import Any
from kirin.dialects.ilist import IListRuntime  
ElemT = TypeVar("ElemT")
N = TypeVar("N")

IList = IListRuntime[ElemT,N] | list[ElemT]

def myfoo(vars: IList[float, Any]):
    return vars[0]


myfoo([1.,2.,3.]) # linter will be happy

[Roger-luo]

I thought @kaihsin was against having list in type annotation :-)

[kaihsin]

This approach user will annotate as the same as IList in their the code, and linter will be happy too

[Roger-luo]

how do you construct an IList outside of the kernel tho? Or we are accepting list and convert it into IList implicitly?

[kaihsin]

I think we should implicitly convert to IList implicitly, depending on the methods' dialect group. If a given method has IList or list

…

On Thu, Feb 20, 2025, 17:31 Xiu-zhe (Roger) Luo ***@***.***> wrote: how do you construct an IList outside of the kernel tho? Or we are accepting list and convert it into IList implicitly? — Reply to this email directly, view it on GitHub <#277 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFCX3SKZTOMVN5O3GDRT56D2QZJSJAVCNFSM6AAAAABXPBI63GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNZSHAZTOMZQGQ> . You are receiving this because you were mentioned.Message ID: ***@***.***> [image: Roger-luo]*Roger-luo* left a comment (QuEraComputing/kirin#277) <#277 (comment)> how do you construct an IList outside of the kernel tho? Or we are accepting list and convert it into IList implicitly? — Reply to this email directly, view it on GitHub <#277 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFCX3SKZTOMVN5O3GDRT56D2QZJSJAVCNFSM6AAAAABXPBI63GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNZSHAZTOMZQGQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[Roger-luo]

I think we should implicitly convert to IList implicitly, depending on the methods' dialect group. If a given method has IList or list

how do you construct an IList then? always via IListRuntime or just treat list as IList if the dialect group contains ilist dialect?

Another question is if we are actually using IList under the hood, what do we return as a runtime value? IListRuntime?

This is now also in conflict with the explicitly annotated element type in an IList - when one converts the syntax [...] into IList there is no such knowledge of element type and thus we have mark it as Any.

---

I feel supporting this as a syntax sugar is problematic in Python, we should just use the plain constructors instead of trying to support another syntax sugar - it's just not possible in Python.

[Roger-luo]

I think another way of doing it is just treat all list as IList implicitly (e.g during type inference). As long as we don't provide methods to mutate the object the semantics here is still consistent with a standard Python list. So basically always annoate the wrapper with list instead of IList - we can always do a conversion to IList at the entry point anyways.