TysonRayJones
commented
3 weeks ago Hi Ananthakrishna,
QuEST is an imperative simulator; it does exactly what you tell it, step by step. Having a circuit type would indeed be convenient, but we've so far decided this is not worthwhile at the level of QuEST where we are restricted to a C-compatible interface. Unless we can abstract it very well using C++, the necessary C memory management to maintain and modify circuits would be nightmarish.
Instead, we have let downstream projects like QuESTlink and pyQuEST define their own circuit structures natural to their language. For example, QuESTlink uses a list of Mathematica symbols and pyQuEST uses a list of Python objects.
As such, we've so far agreed there is a very small need for a usable user-facing circuit structure at the C level. There is an additional case to be made that such a structure would allow us to do all sorts of additional circuit-wide optimisations to massively speedup subsequent simulation. That would still however mean we must develop a circuit optimiser/compiler in C++, whereas such inexpensive, high-level logic is better suited to high-level languages like Python (indeed, QuESTlink already has such a compiler). We could instead integrate an existing C++ compiler like tket, although this breaks our design rule of "use few, if any, external dependencies".
It remains an interesting idea to optionally integrate with tket, which is incidentally something we recently discussed! Alas, I'm doubtful it will come soon, and certainly cannot be fit into our backlog for our mid-September QuEST v4 release.
I'll keep this issue open to inspire more discussion, and report back to if our plans develop!
It would be nice to be able to build composable circuits, like how one can use qiskit.append/qiskit.compose.