[RFC] dialects: (stabsim) stim dialect generalisation

[kimworrall]

We are considering porting a version of the stim dialect from xdsl into xdsl-quantum, but there needs to be some discussion on how this is done.

The original dialect was for direct compatability of the existing QSSA and QREF dialects with the stabiliser simulator tool Stim.
The main use of Stim in existing compiler toolchains is for calibrating decoders for error-correction, which requires the circuit to be run and a model of the hardware it will be run on. There are now other

The problems are:

1. The stim dialect has too many duplicated operations, and should be streamlined to only contain things relevant to stabiliser simulation
2. It is too specific to the Stim simulator, rather than fulfilling a more general purpose i.e. decoder calibration

The key properties of the Stim dialect are:

• stabilisers and stabiliser measurements, which must be adapted to use QuantumOperationAttribute
• hardware specific attributes, ie. layout, noise model - which should be moved to their own dialect
• detectors, which should be given an explicit operation
• ability to run a stabiliser simulator (e.g. Stim) as part of the overall compiler pass pipeline

Looking for comments on:

1. splitting the dialect into several more purposeful dialects
2. ways to adapt it to support either more general decoder calibration or better support for stabiliser simulation

[superlopuh]

I might be wrong, but these seem like slightly different concerns. In my understanding, stim would be a kind of in/out representation, that would be convertible to/from a text format. We could also have a bunch of dialects that correspond to each of the levels of abstraction that you describe. It's not clear to me whether the STIM ops would have the ideal form to do those analyses anyway, and the separation would give us freedom to iterate on how to model the ops that we operate on separately from the parsing/printing dialect, as long as they can be translated between. Does this make sense? That way the creative decisions are mostly left out of the first phase, and we just build a representation that can be parsed/printed.

[alexarice]

I agree that having more general dialects makes sense, but also think we should have specialised "endpoint" dialects for existing formats, whose only job is to input and output those formats.