Do we enforce linearity of static edges (if linear-typed)?

[acl-cqc]

We decided that Constants should be able to be of linear type - for example, a really big structure, where linearity enables in-place mutation.

So, load_constant produces a value edge that may have linear type, and if so, we can't copy that, we can't send that value down an inter-graph edge, etc. Fine.

But what about the static edge from the Constant to the load_constant node? How many of those can I have?

• If we enforced "only one static edge", that would in theory allow in-place mutation of the constant without loading it (if memory access permissions allowed, by directly modifying the constant pool entry). That is, we'd apply the same rules for static edges as value edges. (In which case, should we make Constant nodes just produce value edges?) (No, I guess we have a special case for an edge from a Constant node in the module to an op anywhere in a function body? But then you could load the constant many times so we have the same problems as the next)
• Otherwise, we allow multiple static edges - so load_constant is (as expected) copying that data out of the constant pool; if we can do that once, we can do it many times; the fact that memory constraints mean only one such constant is alive at a time is a different kind of problem (memory allocation, liveness, etc.) that we cannot solve with edges and should not look to (e.g. you could load_constant a "linear" constant in each iteration of a loop and append it to a list!). Note that a single inter-graph edge raises the same problems as many local edges.

Neither of these options make much sense to me and I am wary of allowing load-constant in this way. I think the "non-copyable" values might have to be produced by runtime operations - an example might be "open network connection"...

[acl-cqc]

I think the simplest thing one might say is - if we have multiple static outputs from a Constant then each load_constant is a kind of copy - and linear types cannot be copied. So, a single static output only, don't allow inter-graph edges. Then the only linear constants will have to be local ones?

No, even then you declare a constant in a loop, and copying abounds.

[acl-cqc]

So, if loading a constant is copying it, constants have to be copyable. If you want something like load_constant - then rather than providing a struct with an impl CustomConst, provide a new Op that produces these linear values. Parametrize it by (perhaps-opaque) "instructions for producing a copyable value" - of course these instructions have to be copyable, indeed Equatable.

[ss2165]

How about:

HUGR linearity (:= one connection from port) is defined only on Value ports, not Static. Loading static data from the program in to the runtime is always a copy (I can't picture a system where this isn't the case tbh, unless what you're actually enforcing linearity on is references to static constants).
Since our main use for linear types is quantum types, for which you can't have static constants, I think this is a reasonable compromise.

[acl-cqc]

Loading static data from the program in to the runtime is always a copy (I can't picture a system where this isn't the case tbh,...

In which case shouldn't the type say it's copyable?

, unless what you're actually enforcing linearity on is references to static constants).

If we mean, mutable references - the scary case here is that one invocation of a function could mutate that data, and then a second invocation....would see the mutation from the first??

• So the data is a mutable cache or similar?
• (No) parallelism??
• If it's really a static constant (immutable), there is no problem in copying it. (E.g. our &'static str)

[ss2165]

In which case shouldn't the type say it's copyable?

Not if "copyable" is only referring to copying runtime values, loaded in to scope.

[acl-cqc]

Hmmmm, I agree that is a distinction one could make, but I am not sure it's one I would make, whether it's really worth it. The load_constant somehow has to transform whatever representation it's got into a "runtime value", so either that is a copy, or else dyn CustomConst needs to provide some way to do that (for whatever probably-tool-specific runtime representation we have). I think I'm still leaning towards no change and you should have a CustomOp instead...

[ss2165]

Resolving:
keep static constants as copyable
if non-copyable static constants are useful they can be implemented as custom operations in extensions