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.

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

Relax restriction on root node. #98

Merged
merged 2 commits into from
May 30, 2023
Merged

Relax restriction on root node. #98

merged 2 commits into from
May 30, 2023

Conversation

cqc-alec
Copy link
Collaborator

Update spec as per #94 .

@cqc-alec cqc-alec requested a review from ss2165 May 30, 2023 14:21
@aborgna-q aborgna-q added the spec Issues to do with the specification document(s) label May 30, 2023
Copy link
Member

@ss2165 ss2165 left a comment

Choose a reason for hiding this comment

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

Thanks!
I think it might be simpler to just say the root can be any container node? Then in the table just comment that the parent column only applies if the container node is not root.

executable.
An **executable HUGR** or **executable module** is a loadable HUGR where the
root node is a [Module](#module) node whose first child is a `def` called
“main”, that is the designated entry point. Modules that act as libraries need
Copy link
Member

Choose a reason for hiding this comment

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

for another PR but just noting that we also need to make function names not metadata at which point main no longer needs to be the first.

@aborgna-q
Copy link
Collaborator

aborgna-q commented May 30, 2023

I think it might be simpler to just say the root can be any container node?

Does it even need to be a container? We may just have a single leaf node (E.g. in some replace operation).

@cqc-alec
Copy link
Collaborator Author

I think it might be simpler to just say the root can be any container node? Then in the table just comment that the parent column only applies if the container node is not root.

Yeah I wondered about this, and even whether there was a good reason not to allow any type of node. But maybe some nodes can't really be decontextualized -- like Input and Output (which aren't container nodes), and BasicBlock (which is). Do you think a standalone BasicBlock makes sense?

@aborgna-q
Copy link
Collaborator

aborgna-q commented May 30, 2023

I don't see any reason to disallow those, they may be used during some operations. As long as the executable HUGRs and loadable HUGRs are well defined, the rest can be just a piece of a bigger hugr. (We need to relax the validation of the root node, e.g. for connected ports).

With something like that, we could maybe define a pure view on a HUGR that just exposes a single node and their children (say, focused on a basic block).

@ss2165
Copy link
Member

ss2165 commented May 30, 2023

Happy with no restriction on type of root node. I think we should say somewhere near the top that the type of the root significantly affects the interpretation of the HUGR though.

@cqc-alec
Copy link
Collaborator Author

Happy with no restriction on type of root node. I think we should say somewhere near the top that the type of the root significantly affects the interpretation of the HUGR though.

Allowing BasicBlock nodes to be root would invalidate some statements in the spec such as:

The first output of the DSG contained in a BasicBlock has type Predicate(#t0, #t1,...#tn), where the node has N successors, and the remaining outputs are a row #x. #ti with #x appended matches the inputs of successor i.

We could say "except when the BasicBlock is a root", but I don't see that it has much meaning then.

@ss2165
Copy link
Member

ss2165 commented May 30, 2023

Allowing any nodes other than module as the root invalidates edge validities. For instance, you include DFG and CFG but they currently require their internal and external signatures to match (internal signatures of BasicBlock in the CFG case). We just need to add a line about root node having no edges and how that supersedes other requirements.

Copy link
Member

@ss2165 ss2165 left a comment

Choose a reason for hiding this comment

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

👍

@cqc-alec cqc-alec merged commit 28b8b89 into main May 30, 2023
@cqc-alec cqc-alec deleted the modular-hugr-spec branch May 30, 2023 16:08
cqc-alec added a commit that referenced this pull request May 31, 2023
doug-q pushed a commit that referenced this pull request Oct 21, 2024
## 🤖 New release
* `hugr-llvm`: 0.4.0 -> 0.5.0

<details><summary><i><b>Changelog</b></i></summary><p>

<blockquote>

## [0.5.0](CQCL/hugr-llvm@v0.4.0...v0.5.0) -
2024-09-16

### New Features

- Add emitters for int <-> float/usize conversions
([#94](CQCL/hugr-llvm#94))
- [**breaking**] array ops
([#96](CQCL/hugr-llvm#96))
- Add conversions itobool, ifrombool
([#101](CQCL/hugr-llvm#101))
- Add `tket2` feature and lowerings for `tket2.rotation` extension
([#100](CQCL/hugr-llvm#100))

### Testing

- Add execution test framework
([#97](CQCL/hugr-llvm#97))
</blockquote>


</p></details>

---
This PR was generated with
[release-plz](https://github.com/MarcoIeni/release-plz/).
doug-q pushed a commit that referenced this pull request Oct 21, 2024
…#105)

Also sanitizes the READMEs a bit.

The last attempt to publish a crate using release PR #98
[failed](https://github.com/CQCL/hugr-llvm/actions/runs/10886782954/job/30207610938)
with:
```
error: failed to publish to registry at https://crates.io/
    
    Caused by:
      the remote server responded with an error (status 400 Bad Request): wildcard (`*`) dependency constraints are not allowed on crates.io. Crate with this problem: `serde` See https://doc.rust-lang.org/cargo/faq.html#can-libraries-use--as-a-version-for-their-dependencies for more information
```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
spec Issues to do with the specification document(s)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants