[UX][DISCUSS] Runtime Repr of Tuple
tqchen opened this issue · 4 comments
Right now we lower Tuple to ADT.
However, it is good to consider consistency in the following cases:
- How is tuple being pased by the user (from language frontend) in the most natural way.
- How is tuple being handled by the builtin packed func in C++.
- How is tuple being returned to the language frontend.
Considering all these factors, it might be useful to get some level of consistency here. Right now from fronend and most of the processing code, we are using runtime.Array in the place of tuple.
As a matter of fact, ADT and runtime.Array are backed by same backend implementation (inplace_array). It might be useful to consider lowering Tuple to runtime.Array so we have this form of consistency (e.g. can directly pass a python tuple into a function that takes a tuple, which frontend automatically converts to runtime.Array).
Previously tuple/list distinction was needed in python because list is muttable. In the case ot TVM, Array is an immutable data structure and copy on write when we perform operations in c++(which can create a new Array). So TVM's Array is more akin to an immtutable tuple than a mutable list from object point of view.
In short, we could consider lower tuple to runtime.ArrayNode, so we have this form of consistency.
It might make sense to keep it as ADT if we end up adding other ADTs into the language, so that depends on what our plans are.
We still leverage ADT for other ADTs, since most ADTs are more akin to namedtuple in python rather than tuple, which allows us to even build more things such as named reflection support into ADT if desirable(that is not wanted by tuple). The tuple itself is somewhat differently from namedtuples, as a result could merit a a separate runtime repr, we tied it into ADT mainly because initially we didn't have robust runtime Array object support (which we do now thanks to changes from @junrushao and others).
I would say that 100% of the difference between an ADT and a tuple is the name, but being able to turn Python tuples directly into TVM arrays is definitely a benefit, so that seems like a good reason to make the change.