Remove extension sets

[ss2165]

Discussed in #1894

^{Originally posted by zrho January 27, 2025}
Extension sets add a non-trivial amount of complexity that is pervasive throughout many parts of the compiler. While I understand the motivation, I am not convinced that they carry their weight. I propose that we consider simplifying the compiler by removing extension sets.

[acl-cqc]

So the idea here is that if an op "requires runtime support", instead you'll feed in an extra input of a custom type that means "the extension is present" (0-bits at runtime).

This is a bit like the order/effect types of https://github.com/quantinuum-dev/hugrverse/issues/116 BUT

• can be freely copied (? probably?) as we don't want to totally-order every operation using an extension. (We could use copy/merge but that's a PITA). Hence, probably also discarded, and is an input to each op but not an output.
• cannot be returned through an Output node. (This is necessary for type-checking to guarantee the properties we want!)

There is a big downside though.

• It'll be annoying to build graphs like this...I mean, this is an IR, we can live with some ugliness, but it'll be a lot worse than at present
• It'll be particularly annoying to turn on/off (like we do with the extension inference feature ATM), because adding/not-adding all those ports will affect indexing etc. all over the place
  • And transforming ops (adding/removing such inputs) will be more difficult too.....one goal of an IR being, to ease transformation.....

EDIT: maybe metadata works better than extra inputs

[acl-cqc]

....but metadata cannot be applied to arbitrary points in a type tree, only to nodes. This might be something that we can handle in hugr-model (@zrho ?) - in which case, if we remove extension sets now, we probably can't bring them back until HugrV2 arrives. (That might be ok...)