Use extOps definitions from hugr-py 0.8 #412
Assignees
Milestone
Comments
github-merge-queue bot
pushed a commit
that referenced
this issue
Sep 6, 2024
Updates guppy to use extension operation definitions instead of opaque ops defined on the fly. Some relevant changes included: * Defined a new `guppylang` extension with two ops: `partial` and `unsupported` * Most list and array operations currently emit `unsupported`, as they require custom hugr building code (the core ops in `std.collections` don't match the python operations 1 to 1, it'll need some custom compilation code). * Changed `module.compile` to produce a `Package` containing the hugr along with the required extensions to interpret it. (Currently hardcoded, we should infer which extensions are needed at some point). * We hardcode the tket2 extension jsons. The plan is for `tket2` to publish a new library exporting those, but for now we need the jsons for validation. * Use the prelude operations exported by hugr for most int/float/logic/conversion builtin definitions. The `tket2` dependency is currently pinned to a commit hash, I'll update it once `0.3.0` is released. - Closes #442 - Closes #411 - Closes #412 - Closes #410 BREAKING CHANGE: Bumped the `hugr` dependency to `0.8.0` --------- Co-authored-by: Agustin Borgna <agustinborgna@quantinuum.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
hugr-py 0.8will export all the std operations defined as as extension ops.(Backed by a single centralised extension definition).
CQCL/hugr#1459
We should be able to replace the hacky opaque op definitions in
.prelude._internal.util/.prelude.builtinswith direct references to the operations.The text was updated successfully, but these errors were encountered: