Serializing edges

[ss2165]

In the serialization spec currently all edges are defined as pairs of (node, port). However in the main spec ports are only used for input/const_input/output

I propose instead to move to pairs of (node, Option[port]) such that control flow edges can be expressed as ((node, port), (node, null)) and order edges as ((node, null), (node, null)).

@mark-koch does that work for guppy?

[mark-koch]

Yes that should work. Definitely better than the current solution 👍

I'm wondering if we also have to discriminate between order- and const-edges in the serialised format? Or can the correct one always be inferred from the context?

[ss2165]

const edges have ports and always come after value, order edges don't have ports

[mark-koch]

Oh I see, I got confused by this bit in the spec:

• constN<T> : a static constant value of type T stored in the node weight (perhaps a computation of some Graph type represented as a HUGR). Has no ports, but may have any number of ConstE out-edges - one for each use.
• def : a function definition. The name of the function is specified in the metadata and function attributes (relevant for compilation) define the node weight. The function body is defined by its children (the child graph forms the body). The node has no ports but may have any number of ConstE out-edges - one for each use.

So constN and def nodes have ports? Btw I assume those cannot be copied implicitly, i.e. we need a new port for each use?

[ss2165]

with #80 both constN and def will have one port only, with multiple edges
spec update in progress...

[aborgna-q]

I think this change to the spec was merged in #108. Should we I open the implementation issue, or are there still things to discuss?

[ss2165]

Moved to implementation #133