-
Notifications
You must be signed in to change notification settings - Fork 5
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
refactor!: Separate Signature from FuncValueType by parametrizing Typ…
…e(/Row)/etc. (#1138) * Type now means a single type, not a row variable; TypeRV can be a single type *or* a row variable. (Type --Into--> TypeRV). * These are actually parameterizations: `TypeBase<NoRV>` (NoRV is a type with no instances) vs `TypeBase<RowVariable>` (RowVariable is a struct i.e. index + bound) * Similarly for the other type structures - all names have changed uniformly except FunctionType: | No Row Vars | With Row Vars | Generic | | ----- | ----- | ----- | | Type | TypeRV | `TypeBase<RV>` | | TypeRow | TypeRowRV | `TypeRowBase<RV>` | | Signature | FuncValueType | `FuncTypeBase<RV>` | | PolyFuncType | PolyFuncTypeRV | `PolyFuncTypeBase<RV>` | * This allows us to make static guarantees (and remove dynamic checks): * node signatures do not have row variables as inputs or outputs * Neither do FuncDefn type schemes, even though they may quantify over row variables * "port"-indexing methods are specific to Signature (not FuncValueType) - this justifies the exceptional naming Planning to rename PolyFuncType to (Op/Fn)TypeScheme in a followup PR (lots of fields want renaming too, whereas many FunctionType things are *already* called `signature`!) **One question** is that currently `Type` and `TypeRV` are aliases for instantiations of `TypeBase`. An alternative is to parameterize `Type<RV: MaybeRV = NoRV>` and define as alias only `type TypeRV = Type<RowVariable>` (no `TypeBase`). A type annotation e.g. `x: Type` then uses the default, but a call like `Type::new_function` then tries to infer a unique possible parameter. This would slightly worsen Hugr-building code (some code like `let x = Type::new_function` have to become either `let x = Type::<NoRV>::new_function` or `let x: Type = Type::new_function` - sadly the *default* for RV is ignored for members/namespacing but not when forming a type, see rust-lang/rust#98931). OTOH some OpDef code would be a bit easier (needs fewer explicit `RV` suffices). In general I think we favour making Hugr-building code as easy as possible over OpDef code, but there is always the question of, *how much* easier etc...see commit bc565ba which removed defaults for Type (with an earlier parametrization by bool true/false rather than by RowVariable/NoRV). (And actually that commit understates the simplification - there were a bunch more `let x:Type`s required for the default method that can be removed for the always-explicit method, I took these out in 23db41d, so maybe we should stick with always-explicit.) * [ ] TODO python classes need names updating to match, etc. BREAKING CHANGE: (1) In OpDefs, Type/TypeRow/FunctionType/PolyFuncType will generally need replacing by TypeRV/TypeRowRV/FuncValueType/PolyFuncTypeRV. (2) FuncValueType omits the various numbered-"port" accessors, you really shouldn't be doing that except on a Signature.... (4) SignatureError::RowVarWhereTypeExpected now contains a RowVariable struct (including bound) rather than only the index
- Loading branch information
Showing
61 changed files
with
1,368 additions
and
1,033 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.