Thanks @electriclilies for writing the summary. Would like to share some thoughts along these lines. The particular discussion are related to two design principles we followed so far.
### C0: Python as a First Class Citizen One of the key design principles we have followed so far is to make python a first class citizen. The rationale is that we want to make sure that users/developers can easily compose up optimizations passes, do transformations and manipulate the IR(as a way to do quick prototyping) in python. As a result, developers can bring in new operator definitions, crafting importers and scheduling in a much faster pace. This design principle also enables us to quickly interact with the machine learning based cost models, most of which are based on python. Finally, researchers are able to plugin their own methods much more easily into the ecosystem. In short, python as a first class citizen is helps to to make the framework accessible to more people. So while such design principle certainly brings restrictions, it is also deeply rooted in the framework design philosophy that allows us to build an optimization framework that is modular, extensible and easy to sue. We can see a lot of similar philosophy being adopted in frameworks like PyTorch. First class integration with the python ecosystem have been is a key point that we choosed differently from some of the existing solutions. ### C1: C++ as the Stable Core While making things python friendly is important, it is equally important to think about a stable APIs and avoid implementation divergence. We have followed a principle that most of the stable implementations should be implemented in C++(while the object system makes them language agnostic). This has been the case for compiler passes and most of the infrastructure. ### Discussions While it is easy to give absolute priority to either C0 and C1, the most interesting question comes when we start to consider both. Specifically, how can we create a modular API that follows C1, while still enables C0? This is a harder but more interesting question we should ask ourselves. For example, one extreme is to implement every step of compilation in C++, and only allow invocations through a CLI style interface. This extreme can create a big barrier for customization. So the main question we are facing right now is how to maintain both C0 and C1 as much as possible. To solve this problem from the root, **C2: Modularization** would be key. Right now `lower` and `build` are monolithic APIs that does the TIR optimization, lowering and compilation in a single shot and it is really hard to inject things in between. Imagine that instead we create a API that returns the Pass pipeline(as a list of passes) to the user, which will be invoked by build. If developers want to further customize the pass pipeline, they can manipulate the list of passes further(e.g. by add or deleting passes). Such new API would allow customization without much divergence because the default compilation pipeline is still defined in one place, while still enabling a good level of customization in python. Thinking about the current state of the codebase. There are components that are still implemented primarily in python, including some of the frontend importers, connection to machine learning toolkits(that have to depend on python), as well as some TOPI schedules(the community made a choice to focus on python). So it is unlikely that we are going to eliminate python completely. However, I think we tend to agree that as we have an idea of a stable API, C++ is preferred(while keeping C0 in mind and expose a pythonic interface). As a result, I think it is a good idea to require Option1 for new python APIs. We should also start gradually add typings to the python APIs so that we can turn on mypy checkings in the CI for future enforcement. While it could take some effort, doing it incrementally will likely gives us much benefit. --- [Visit Topic](https://discuss.tvm.apache.org/t/rfc-bifurcation-of-apis-across-python-and-c-a-case-study-and-recommendations-for-prevention/10203/3) 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/c6db4a306e451fcf4dfc272f3c495b43d01f97b8e67419a530ac0f27e5e0eb7a).
