Repository navigation
Replies: 1 comment 6 replies
|
I'm quite against adding metadata to order edges. We should instead use value edges. I suggest we:
|
|
hot take: I don't know what OrderType is and I don't like it! I strongly want these tokens to be value edges because I want to pass data through them |
I think this means we don't want drop because we want to force it out of the output node. If so yes, we do! Ok, so the thing you are optimising for is a cleaner graph, with implicit dups/joins. So another alternative would be allowing some value edges of some types to have multiple inputs? Again, for this to be useful (to me) we have to be able to lower these edges to runtime values We can mechanically transform your order edges into linear-values-with-explicit-dups-and-joins, although it may require two version of each extension, explict-tokens and implicit-tokens. I suppose this would be fine. I think one "advantage"(I don't understand well enough to approve, but it's interesting) of the order edges is that it's entirely local to a function, not part of it's signature? I'm not convinced by "too-many-dups-joins", but y maybe it is too expensive. Linear tokens, and telling guppy it's dup/join op, solves the problem and is the simplest thing I think? |
|
They could be a kind of Value, yes, but they break the rule common to all other values (linear and classical) of only one incoming edge. So in some sense they seem more different to both linear and classical than linear and classical are different to each other. But maybe this is a presentational thing. These edges/ports would be part of a function's signature, and that's intentional by design - current order edges feel like too much of a wild west there. (E.g. optimizations were getting messed up by pure quantum ops having order edges to them; this scheme forbids that - until we add explicit GlobalFlags ports.) I see nothing that says "only Value edges can compile to passing values at runtime".... and inserting dups/joins late in compilation would be fine, if its useful. (I'd keep these new edges as local only so adding dups/joins is straightforward.) fwiw I see a common case of multiple incoming edges as being, all the inputs have "borrowed" the value (perhaps immutably), all must complete before the node can modify it. These edges (modelling arbitrary dup/join) are more flexible than "borrowing" (i.e. they do not strictly enforce a borrowing regime). Perhaps something more explicitly about borrowing would be useful to the runtime - so when there are multiple outgoing edges, you pass (immutable) pointers; only when all merged, do you get the value back - we could make that more explicit in the Hugr ("borrow edges" or something perhaps), and that'd correspond to inserting more complex patterns of ops than "simple" dup/join. But it'd also be less flexible. Happy to entertain that discussion ;) (Viewed from that perspective, the "TypedOrder" edges I'm suggesting would mean, the value being dup'd/join'd is a pointer, to a single instance of that "OrderType". But, I leave it to guppy to generate patterns of edges such that ops that are going to mutate the value being pointed at, only occur when that op has the unique pointer; the hugr does not enforce such. We could make hugr enforce that but it would be more complex.) |
|
so a function that uses one of these edges would have it in it's signature? and there are rules for how it propagates for CFG etc? What you are describing is even better for runtime because we know that every edge of that type has the same value, so it is constant in the function. How does this work for "callback-style" ops like |
Yeah, they would be the same as for Value edges. Hmmm....
Yes, something like that! One could explicitly write them for both inputs and outputs: |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
We want to distinguish order edges that are there for different reasons - otherwise we have to assume every edge might be there for every reason, which results in a kind of cross product. (Not too painful while there aren't many order edges but we're gonna see a lot more...)
I see a couple of options:
I'm gonna concentrate on (2.) here and try to solve some of the problems of the current Order edges. Besides that we can't identify what any Order edge is for, another problem is that nodes can arbitrarily discard Order (have Order inputs and no outputs) or produce it (outputs and no inputs) - ops do not specify their Order inputs or outputs. This would be one advantage of switching from Order to linear Value tokens, but for many of the ordering constraints that we want in practice, linear is too restrictive (as it requires a total order of ops). Rather the ideal would be - as a new EdgeKind variant, so showing existing variants for comparison:
That is, whereas classical Values can be copied and discarded (but linear cannot), the new EdgeKind supports copying and merging (aka joining), but not discarding. (Better names invited!)
We would then allow Extensions to define "types" for these edges (maybe
OrderTypes ?) - these could be a lot likeExtensionTypes (but not FunctionTypes or SumTypes so they are notTypes), so we could add a new variant ofTypeDefBoundallowing such to be created by an extension TypeDef (including parametrized - so an extension could define an arbitrarily large family of OrderTypes - ideal for, say, uses of different global variables).All reactions