Extension sets do not spark joy

[zrho]

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 goal of extension sets was to allow having functions, blocks, (perhaps higher-order/runtime closures, perhaps static) that indicate the hardware capabilities they require to run on, thus gaining us the ability to statically check that we won't get any errors "tried to execute this quantum/GPU-requiring program on hardware without this".

So, if we drop extension sets, I think this would mean either

• We decide we have no interest in doing that - EDIT: (I realize) Tierkreis was the specific use-case here and this may not be a priority...
• We have other (better) ways of doing that

I'm not sure which you mean, can you elaborate?

[ss2165]

Summary of discussion with @acl-cqc (correct if I've misunderstood):

• There remain use cases for Tierkreis which may benefit from having this information encoded
• HUGR use for Tierkreis remains speculative, especially given ongoing redesigns of Tierkreis
• It may be that something more general like an effect system captures this better than a bespoke system like extension sets
• Simplifying the model now has high value for near term target of stabilisation

Conclusion: remove extension sets 🔪

[acl-cqc]

I think I'd be slightly more cautious but that is probably it.
Specifically - if we omit extension sets, can we do this with metadata instead? In particular, hugr-model "typed metadata"? In the limit, we might want to get back to the current hugr-core extension set mechanism, although most likely, the system we want may be different and this will likely become clearer when we want it....

[ss2165]

Moved to issue #1906