-
Notifications
You must be signed in to change notification settings - Fork 11
Sketch out resources + extension mechanism, update CustomType #186
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
Changes from 19 commits
cb7d892
2e46435
5c38679
768186f
6a791d0
be533e8
6f32b4a
94270ab
9d975be
a5aab3c
32789f8
c13509e
fd54ace
cfcc55e
d9bb37f
a1ebf02
bd0f5b1
0aabce2
b94c1d2
ab6b9dd
e35ef58
67f2a0a
fe9dcef
01251de
a4b0170
efe7fab
7d7184f
da9bd1f
8b757c9
dd988f6
bc44593
c551a8e
b6f4edc
36a9c2f
d44db52
d298e17
9dfc773
62f14b6
27b1d32
039bd9d
4dd0c8b
600766b
b5b7620
8cc4815
cbeadb7
bcab91d
2b79270
0b13226
a3a4b45
9d56a53
52a5534
8ca2b7d
c0e74eb
eb6ee7b
08311b8
d20f304
39eb159
0d34eee
8be5c30
b556674
d7bade1
564a33d
6abce77
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -713,7 +713,7 @@ resources: | |
types: | ||
- name: QubitVector | ||
# Opaque types can take type arguments, with specified names | ||
args: [["size", u64]] | ||
args: [["size", Int]] | ||
operations: | ||
- name: measure | ||
description: "measure a qubit" | ||
|
@@ -741,9 +741,9 @@ resources: | |
- name: MatMul | ||
description: "Multiply matrices of statically-known size" | ||
args: # per-node values passed to type-scheme-interpreter and used in signature | ||
- i: U64 | ||
- j: U64 | ||
- k: U64 | ||
- i: Int | ||
- j: Int | ||
- k: Int | ||
signature: | ||
inputs: [["a", Array<i>(Array<j>(F64))], ["b", Array<j>(Array<k>(F64))]] | ||
outputs: [[null, Array<i>(Array<k>(F64))]] | ||
|
@@ -752,7 +752,7 @@ resources: | |
- name: max_float | ||
description: "Variable number of inputs" | ||
args: | ||
- n: U64 | ||
- n: Int | ||
signature: | ||
# Where an element of a signature has three subelements, the third is the number of repeats | ||
inputs: [[null, F64, n]] # (defaulting to 1 if omitted) | ||
|
@@ -761,19 +761,30 @@ resources: | |
description: "Concatenate two arrays. Resource provides a compute_signature implementation." | ||
args: | ||
- t: Type # Classic or Quantum | ||
- i: U64 | ||
- j: U64 | ||
- i: Int | ||
- j: Int | ||
# inputs could be: Array<i>(t), Array<j>(t) | ||
# outputs would be, in principle: Array<i+j>(t) | ||
# - but default type scheme interpreter does not support such addition | ||
# Hence, no signature block => will look up a compute_signature in registry. | ||
- name: GraphOp | ||
description: "Involves running an argument Graph. E.g. run it some variable number of times." | ||
args: | ||
- r: ResourceSet | ||
signature: | ||
inputs: [[null, Graph[r](Int -> Int)], ["arg", Int] | ||
outputs: [[null, Int]] | ||
resources: r # Indicates that running this operation also invokes resources r | ||
``` | ||
|
||
The declaration of the `args` uses a language that is a distinct, simplified | ||
form of the [Type System](#type-system) - writing terminals that appear in the YAML in quotes, | ||
the value of each member of `args` is given by the following production: | ||
``` | ||
TypeParam ::= "Type" | "ClassicType" | "F64" | "U64" | "I64" | "Opaque"(name, ...) | "List"(TypeParam) | ||
TypeParam ::= "Type" | "ClassicType" | ||
| "F64" | "Int" | ||
| "Opaque"(name, ...) | "List"(TypeParam) | ||
| "ResourceSet" | ||
``` | ||
|
||
**Implementation note** Reading this format into Rust is made easy by `serde` and | ||
|
@@ -782,9 +793,11 @@ Serialization section). It is also trivial to serialize these | |
definitions in to the overall HUGR serialization format. | ||
|
||
Note the only required fields are `name` and `description`. `signature` is optional, but if present | ||
must have children `inputs` and `outputs`, each lists. The optional `misc` field is used for arbitrary | ||
YAML, which is read in as-is and passed to compiler passes and (if no `signature` is present) the | ||
`compute_signature` function; e.g. a pass can use the `basis` information to perform commutation. | ||
must have children `inputs` and `outputs`, each lists, and may have `resources`. | ||
|
||
The optional `misc` field is used for arbitrary YAML, which is read in as-is and passed to compiler | ||
passes and (if no `signature` is present) the`compute_signature` function; e.g. a pass can use the `basis` information to perform commutation. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I thought the conclusion of the discussion was that data in There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. IIRC we said that if you wanted statically-known floats then you could put that in |
||
|
||
The optional `args` field can be used to specify the types of static+const arguments to each operation | ||
---for example the matrix needed to define an SU2 operation. If `args` are not specified | ||
then it is assumed empty. | ||
|
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.
I changed all the
u64
s toInt
to reflect what's inClassicType
andTypeParam
- and the general policy that the difference between signed and unsigned is in the operations, not the bits flowing around the wires of the Hugr.However, there is an argument that the specification here is not just about the (signedness-independent) serialized form of the parameters, but also an instruction as to how int constants should be parsed / treated by the frontend. If this is left as Int, then some other data somewhere needs to tell any frontend that the value should be unsigned...
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.
Are there any cases where we actually want signed semantics in the uses of
Int
in the core, or should we just say that it's always unsigned (and maybe rename toNat
or something)?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.
I admit I haven't seen a use for a signed int in a type yet.