> The suggestions are made on that basis not only considering embedded C and > rust API(we should of course take that into consideration as part of the > process like you suggested), but also general TVM project(and broader tvm > community) as a whole for this specific context of rust language in this RFC > -- I am only making that suggestion because the generic term rust was used to > normally referring to Bx and the fact that (unlike A~Ax) Bx can be a bigger > set than B.
I would suggest that we don't model TVM as the centre of the universe, the project exists to serve the needs of a far broader development community with language users that better understand their own needs. I've agreed with your sentiments that we should be namespacing and documenting this better; we should make it clear for a C developer to choose the larger dynamic or the dinkier embedded variant of the API in the same way we should make it clear for a Rust developer. This is not the right RFC for that activity. > Having proper namespacing or calrification is not a strong requirement, since > it is not excluding the particular module because of existence of other rust > APIs, and also helps to clearly signal the overall the intent helps to > empower the community members both in A, B, Ax and Bx. Your review is currently requesting changes, if those changes are not a strong requirement can you explicitly approve? -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/96#issuecomment-1375394453 You are receiving this because you are subscribed to this thread. Message ID: <apache/tvm-rfcs/pull/96/c1375394...@github.com>
