From 2e263c60f81d55d0e6f40447e4ccd63d4c2cf6b9 Mon Sep 17 00:00:00 2001
From: Alec Edgington <54802828+cqc-alec@users.noreply.github.com>
Date: Wed, 3 Jan 2024 09:10:07 +0000
Subject: [PATCH] docs: Spec clarifications (#738)

A couple of small clarifications suggested by Will.
---
 specification/hugr.md | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/specification/hugr.md b/specification/hugr.md
index 3c6517dcf..ce989f495 100644
--- a/specification/hugr.md
+++ b/specification/hugr.md
@@ -1234,7 +1234,9 @@ Note that considering all three $\mu$ lists together,
    - the `TgtNode` + `TgtPos`s of all `NewEdgeSpec`s with `EdgeKind` == `Value` will be unique
    - and similarly for `EdgeKind` == `Static`
 
-The well-formedness requirements of Hugr imply that $\mu\_\textrm{inp}$ and $\mu\_\textrm{out}$ may only contain `NewEdgeSpec`s with certain `EdgeKind`s, depending on $P$:
+The well-formedness requirements of Hugr imply that $\mu\_\textrm{inp}$,
+$\mu\_\textrm{out}$ and $\mu\_\textrm{new}$ may only contain `NewEdgeSpec`s with
+certain `EdgeKind`s, depending on $P$:
    - if $P$ is a dataflow container, `EdgeKind`s may be `Order`, `Value` or `Static` only (no `ControlFlow`)
    - if $P$ is a CFG node, `EdgeKind`s may be `ControlFlow`, `Value`, or `Static` only (no `Order`)
    - if $P$ is a Module node, there may be `Value` or `Static` only (no `Order`).
@@ -1262,7 +1264,8 @@ The new hugr is then derived as follows:
 6.  For each node $(n, b = B(n))$ and for each child $m$ of $b$, replace the
     hierarchy edge from $b$ to $m$ with a hierarchy edge from the new copy of
     $n$ to $m$ (preserving the order).
-7.  Remove all nodes in $R$ and edges adjoining them.
+7.  Remove all nodes in $R$ and edges adjoining them. (Reindexing may be
+    necessary after this step.)
 
 ##### Outlining methods