-
Notifications
You must be signed in to change notification settings - Fork 6
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
Conversation
There was a problem hiding this 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 |
There was a problem hiding this comment.
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.
Does it even need to be a container? We may just have a single leaf node (E.g. in some replace operation). |
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 |
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). |
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
We could say "except when the |
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. |
2090342
to
609ba49
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
## 🤖 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/).
…#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 ```
Update spec as per #94 .