I've been looking at the PR and some of the discussion, and I thought I'd bring my thoughts back jto this RFC, it seems like a better place for broader design thoughts.
First, thanks for the RFC, @ziheng. There is definitely waaaay too much boilerplate in TVM right now, and finding ways to streamline that will help development in the future. I'm a still a little confused on what the exact goal of this RFC is. It seems like the current design is as a setup tool: You write it once, execute it once, and then throw away the schema code. After that, you edit and check in the generated code. At most, I think that would save 15-30 minutes of development time per new datatype introduced, I'm not sure it's really worth the complexity of parsing the python AST. If we want to move to a situation where we remove the boilerplate code from the repository and generate it on every build, that becomes a more complicated question. First, declarative code like that can be very difficult to debug, it places enormous pressure on the correctness of the parser implementation. Second, if we do want to move to a system where we automatically generate more of the bindings, I really don't think it should be in python. The more we write core TVM functions in python, the less portable the entire system becomes for lower level production uses and more resource constrained systems. I guess I'm not sure I fully understand the problem this is trying to solve? Thanks, Matthew --- [Visit Topic](https://discuss.tvm.apache.org/t/rfc-tvm-object-schema-dsl/7930/13) to respond. You are receiving this because you enabled mailing list mode. To unsubscribe from these emails, [click here](https://discuss.tvm.apache.org/email/unsubscribe/ae65a4234ac8a233e238bb86cdf7a19a8e4223f9c1b23333950b23a3ee078ef0).
