RFC: Add friction to accessing `annotate`

[johnzl-777]

Currently you can access the annotate dialect via the squin module directly:

@squin.kernel
def demo():
	qs = squin.qalloc(4)
	ms = squin.broadcast.measure(qs)

	squin.set_detector([ms[0], ms[1]], coordinates=(0,0)

While this is great in terms of convenience @david-pl brought up here (#603 (review)) that it's not clearly defined what the user expectation should be if they feed a program with annotation present to other interpreters/emitters for things like PyQrack/Cirq.

@kaihsin pitched this to me in person (and I'm putting it in RFC from to see if there's any reservations about this) that annotate should be something that users would have to explicitly import as opposed to access directly from squin:

from bloqade import annotate

@squin.kernel
def demo(): 

	qs = squin.qalloc(4)
	ms = squin.broadcast_measure(qs)

	annotate.set_detector([ms[0], ms[1]], coordinates=(0,0))

This would be pretty easy to do, I just don't route things through squin but preserve the current squin dialect group definition.

[Roger-luo]

I kinda agree with the proposal here - it's not something you always use (if not for QEC specifically) and people should be aware of what this does.

Would be nice to see @rafaelha 's opinion on this too.

[rafaelha]

That sounds good to me. In principle I don't have a strong preference either way, but the approach here makes sure that the user is more aware of the annotation feature when they use it.

By the way, this also comes up in stim. stim has a measurement sampler (in addition to a detector sampler) that behaves just like a regular sampling simulator. In the documentation it is stated that this simulator will simply ignore detector and observable annotations.

[cduck]

How about squin.annotate.set_detector(...) because annotate will only work in squin kernels?

[kaihsin]

I think my original pitch is... would that make sense to actually be

from bloqade import qec

qec.annotate.set_detector 

because that annotation is actually related to qec?

[johnzl-777]

Sorry about that @kaihsin I might have dropped that detail when I was writing up this RFC 😓

I think there's an added benefit to your proposal too in that if we add more qec-related functionality there's a namespace that's already "reserved".

It might be worth making things a bit simpler and just allowing:

from bloqade import qec

qec.set_detector

Unless there's going to be a large number of potentially "overlapping" statements, like

qec.X.some_statemet
qec.Y.some_statement

Where they should have the same name to indicate very similar functionality but X and Y denote some different part of the qec stack accessible to the user.