Compiling: Organize Gate Relationships

[balopat]

Problem: There are currently 40 different gates in Cirq. Many of these gates are related to each other. A common pattern here is that a gate exists which is a subset of a more generalized gate. This is particularly confusing when one attempts to use isinstance on gates. In addition many gates implement the decompose protocol, and so there is some hidden relationship between these gates when they are decomposed. This feature would be to define what is allowed for the relationship between gates and how decompose should be defaulted and documented. A further question to be resolved in this feature is whether some of this organization should be delegated to gate set concepts.

Rough requirements:

• Catalog current gate relationships
• Define allowed relationships between gates and implement
• Decide how decompose should be used for Cirq gates. For example should decompose not be implemented for the base Cirq gates and only allowed for composite gates that do not define their own action?

[smitsanghavi]

This sounds pretty nice to have. What are the expected benefits of establishing these relationships?

1. A more general isinstance implementation that understands these relationships might simplify some code (Some examples would be great here)
2. Easier Gateset validation/conversion once we have that feature

[balopat]

TODO(@balopat): scope this before we jump in figure out what exactly we want to do before Cirq 1.0

[tanujkhattar]

Colab to visualise current Cirq Gate Relationships.

[daxfohl]

Adding takeaways from conversation with @tanujkhattar for posterity:

• Avoid pushing into protocols if possible -- that hard-codes everything and we want to keep flexibility / exensibility.
• Try to find a MVP use case: is there a set of 5 or fewer gates that we could start with and would add value somewhere?
• Idea: Rule sets that can be mixed and matched, and a rules engine that processes them.