When a bloq doesn't support symbolic decomposition

[mpharrigan]

Many bloqs have registers whose size can be symbolic parameters like sympy.Symbol('n'). If you're using BloqBuilder to wire up a composite bloq, you can wire up symbolically-sized registers just fine. Indeed, if you keep your bloq decompositions as hierarchical as possible you can probably handle at least a couple levels of decomposition purely symbolically.

But sometimes, we need to know the actual value of $n$ because we want to e.g. place $n$ subbloqs in a particular way. Each subbloq is instantiated as a Python object; and we can't have a symbolic number of instantiated Python objects.

The current practice is to add a check to build_composite_bloq that will raise an exception if decomposition is attempted on a parameter configuration for which decomposition isn't supported: usually because an attribute is symbolic instead of concrete. We raise DecomposeTypeError to distinguish between something unexpectedly going truly wrong and raising e.g. a ValueError.

def build_composite_bloq(...):
  if is_symbolic(self.bitsize):
    raise DecomposeTypeError(f"Cannot decompose symbolic {self}.")
  ...

Note how we can provide a helpful error message: the string itself can contain debugging information (like the current bloq's str). The traceback will point to the build_composite_bloq method of the bloq that doesn't support decomposition. The rest of the library will handle DecomposeTypeError gracefully.

If you forget this, you'll get an exception the first time you try to manipulate the symbolic parameter in an unexpected way. This could be: trying to iterate over it or passing it to the constructor of a Split bloq. If you didn't explicitly set up a symbolic BloqExample for testing, the unexpected ValueError will escape testing.

---

Any time you are splitting a register of symbolic size, it will not work. Usually this is "on purpose". So can the system just assume that if you're trying to add a Split with a symbolic size then it's equivalent to DecomposeTypeError and avoid the toil of adding a check to every method? sort of.

Raising a DecomposeTypeError during the initialization of Split doesn't seem morally right. You could theoretically be constructing such an object outside of a decomposition.

We do have BloqBuilder.split as a helper method. It would be great if this helper could help us raise the correct exception. I propose adding the check to BloqBuilder.split(). I want the error message to still be somewhat helpful. I propose that BloqBuilder optionally learns a debug string for the (composite)bloq it's building so it can be used in error messages.