Resource namespacing

[acl-cqc]

#186 implements a two-level system for named Resources containing named OpDefs; the latter's names need be unique only within each resource. However, this probably means we'll be writing out a lot of "TKET/CX"s. (I haven't defined how the two names are combined into a qualified name, i.e. formatting, here.)

This lead to the system of a Map<String, Resource> "registry", input to resolve_extension_ops, where each Resource has a Map<String, OpDef>.

• Another possibility is a completely flat system, where an op name does not identify a resource. So CX is just CX. You then load a bunch of resources and hope one of them defines CX ;). Obviously, this leads to the possibility of name clashes (but we don't avoid that even with the two-level system - resource names themselves could clash). This would allow Resource to keep just a List and then the resolve_extension_ops would take a Map<String, OpDef> containing all OpDefs from all Resources.

The same question also applies to types - is that "TKET.Qubit" or just "Qubit". If the latter, we should reinstate Resource having ResourceSet of dependencies (other resources that define types used in this one). If the former, this could be calculated programmatically by inspecting all the OpDef's in the Resource.

[ss2165]

I like the sound of just flat names, but we need to be able to allow the use of multiple resources that define ops with the same name, so this requires some kind of aliasing?

[acl-cqc]

We might say - this is an IR, not a user-facing language; shortcuts like import CX from TKET should be resolved by the frontend (and then everything is unambiguous in the IR)

[acl-cqc]

But if we are thinking of flat names, let's do some thought experiments....

• So, nodes/ops don't say which resource they are from; resource names exist just for ResourceSet's
• We still have resource names in the type annotations throughout the graph. It would be strange if these became inconsistent (e.g. an implementation of the same op-name was provided by a different resource)
• If you did a rewrite that completely removed a section of the graph (e.g. conditional-predicate-always-true => remove false subgraph), or otherwise required recomputing resource requirements, you're not going to be able to do that if there are 'OpaqueOp's (i.e. just name and serialized signature), or maybe even if there were and you've just removed them...
• The key question might be, What does the aliasing mechanism look like?

[acl-cqc]

Ah, hang on - we can always send some information about the resource - even if not the binary compute_signature, we can package the rest in YAML and include that with the Hugr. So the code (in #186) needs to allow for OpDef's that have no compute-signature (YAML or binary), and we'll only be able to use operations that have the computed signature serialized. Then I think we are pretty much OK.

Moreover the resource YAMLs attached with the Hugr resolves the question of which-op-came-from-which-resource, so that's fine too.

Still need to figure out the aliasing mechanism, though.

[acl-cqc]

One more thought - I can imagine having multiple implementations of the same set of ops in different ways via lowering. Are these different resources (with the same interface), different implementations of "the same resource", ???

[ss2165]

if lowering is a HUGR-> HUGR operation then same resource, different lowering passes (asking an op to lower itself need not be the only way either, arbitrary rewrites can do as they please).

if lowering is a HUGR -> other operation, likely different resources are needed

[acl-cqc]

Yeah, I see lowering as taking a Hugr using some set of resources, and producing another Hugr using a different (perhaps smaller, or more basic) set of resources

[acl-cqc]

Aliasing. (We might want something here even if we have namespaced op names, in case there are Resource conflicts; we'll definitely need it for a flat namespace of op names.)

For functions defined in other Hugrs, we also have a flat namespace. The "solution" there is to Declare individual functions required (not really specifying where they'll come from); any mechanism for resolving conflicts between Hugrs is presumably then a linker directive, which we haven't really spec'ced out (but might not be in the Hugr - flags to the linker, perhaps).

I don't think we want to have a Declare-equivalent for every operation obtained from a Resource, though. But do we need a Rename directive in the Module (that renames an individual op, so original-name + Resource name + new-name; or all ops from a particular Resource e.g. by adding a prefix)?

The problem with Module directives, of course, is they're not very compositional - e.g. if my rewrite wants to splice in a graph containing operations from a new Resource (but these need renaming). I guess that can still be done in two steps, maybe that's ok.

[acl-cqc]

I think discussion in standup (Mon 26 Jun) concluded that we should go with fully-qualified op-names, and fully-qualified/conflict-free resource names, then we don't need an aliasing mechanism. Right? (I guess if so then we can close.)

[ss2165]

sounds good