Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs(spec): Add note on serialized hugr node order #849

Merged
merged 3 commits into from
Mar 6, 2024
Merged

docs(spec): Add note on serialized hugr node order #849

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
e1efb62
doc(spec): Add note on serialized hugr node order
croyzor Feb 27, 2024
5f3eda6
Merge branch 'main' into spec/node-order
croyzor Mar 5, 2024
828aaba
docs(spec): Mention 0-indexing in node serialisation
croyzor Mar 6, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 8 additions & 3 deletions specification/hugr.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1556,8 +1556,9 @@ pseudocode, though we advocate MessagePack format in practice (see
[Serialization implementation](schema/serialization.md)).
Note in particular that hierarchical relationships
have a special encoding outside `edges`, as a field `parent`
in a node definition.
The unique root node of the HUGR reports itself as the parent.
in a node definition. Nodes are identified by their position in the `nodes`
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is already said below, but I think it bears repeating because it's not super intuitive. I'd be glad to hear a rewording that makes it clearer though

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The wording sounds good to me. Maybe we should also clarify that the position is zero-based?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done 👍

list, starting from 0. The unique root node of the HUGR reports itself as the
parent.

The other required field in a node is `op` which identifies an operation by
name, and is used as a discriminating tag in validating the remaining fields.
Expand Down Expand Up @@ -1586,7 +1587,7 @@ struct Edge = ((Int, Optional<Int>), (Int, Optional<Int>))
```

Node indices, used within the
definitions of nodes and edges, directly correspond to indices of the
definitions of nodes and edges, directly correspond to positions in the
`nodes` list. An edge is defined by the source and target nodes, and
optionally the offset of the output/input ports within those nodes, if the edge
kind is one that connects to a port. This scheme
Expand All @@ -1595,6 +1596,10 @@ valid node - whereas in tooling implementations it may be necessary to
implement stable indexing where removing a node invalidates that index
while keeping all other indices pointing to the same node.

Nodes with `Input` and `Output` children are expected to appear earlier in the
list than those children, and `Input` nodes should appear before their matching
`Output` nodes.

## Architecture

The HUGR is implemented as a Rust crate named `quantinuum-hugr`. This
Expand Down