Repository navigation
feat[next]: Add support for tuple comprehensions #2833
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
Open
SF-N
wants to merge
26
commits into
tehrengruber/parameterize-tree-map-elements
from
sf_n_tracer_support
Open
Changes from 25 commits
Commits
Show all changes
26 commits
Select commit
Hold shift + click to select a range
e5b676a
fix[next]: 'concat_where' crashes on local (neighbor-list) fields
tehrengruber 8643e6d
Add 'concat_where' test with nested tuple branches (moved from #2833)
tehrengruber 7b21e9c
feat[next]: Add support for tuple comprehensions
tehrengruber 4a117af
Address Fable review: builtin-constructor arity diagnostic and length…
tehrengruber 666c8b4
Address review comments (unpack diagnostics, DSLError for heterogenei…
tehrengruber 0f11a59
Add empty-tuple comprehension test, xfailed on compiled backends
tehrengruber 681ce77
Add unit test for the generic-tuple constructor type
tehrengruber 5da530e
test[next]: improve coverage for closure vars in tuple comprehension …
havogt dc655ee
Merge upstream/main into sf_n_tracer_support
havogt c1ccbad
Treat operators with variable-length tuple params as generic in '_is_…
tehrengruber 68de5f4
Address review comments (unpack arity, nested vararg concretization, …
tehrengruber 840b85e
Fold the unpack-arity check into 'process_target'
tehrengruber bbb5099
Apply pre-commit ruff formatting
tehrengruber 97576ae
Add TODO about renaming 'VarArgType'
tehrengruber 9d4d8f3
Merge remote-tracking branch 'origin/pr2931' into vararg_program_support
tehrengruber 343ec9b
Fix imports after 'eve.extended_typing' was renamed to 'eve.xtyping' …
tehrengruber effbb2d
feat[next]: variable-length tuple ('tuple[T, ...]') support for programs
tehrengruber 264e753
refactor[next]: rename 'VarArgType' to 'VarLenTupleType'
tehrengruber 8bb2813
fix[next]: don't assert argument compatibility for operator wrappers
tehrengruber 66dabce
fix[next]: lower uncalled programs with their declared parameter types
tehrengruber 3c61f57
Cleanup comments
tehrengruber 0d80c32
fix[next]: derive named-collection member types from runtime values
tehrengruber 7bda923
fix[next]: support named collections inside variable-length tuples
tehrengruber e2d872e
fix[next]: handle variable-length tuple arguments of scan operators
tehrengruber 78bdccb
fix[next]: proper error for static domains with variable-length tuples
tehrengruber a8dbef6
style[next]: fix code quality checks
tehrengruber File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
41 changes: 41 additions & 0 deletions
41
docs/development/ADRs/next/0028-Homogeneous_Tuple_Comprehensions.md
This file contains hidden or 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
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,41 @@ | ||
| --- | ||
| tags: [] | ||
| --- | ||
|
|
||
| # Homogeneous Tuple Comprehensions | ||
|
|
||
| - **Status**: valid | ||
| - **Authors**: Till Ehrengruber (@tehrengruber), Sara Faghih-Naini (@SF-N) | ||
| - **Created**: 2026-08-27 | ||
| - **Updated**: 2026-08-27 | ||
|
|
||
| In the context of tuple comprehensions in the field-view frontend, facing the constraint that every FOAST node carries exactly one type, we decided to support only homogeneous iterables — all elements of the same type — and reject heterogeneous ones in the type deduction. | ||
|
|
||
| ## Context | ||
|
|
||
| Tuple comprehensions, e.g. `tuple(2.0 * el for el in (a, b))`, are typed and lowered with a single mapper: one target (`el`) and one element expression (`2.0 * el`), shared by all elements of the iterable. In FOAST every node has a single `type` attribute, so the target symbol — and consequently every node in the element expression — can only be typed once. If the iterable's elements had different types, the mapper would need a different type per element, i.e. per-element re-typing (monomorphization) of the element expression, which the FOAST type system does not support. | ||
|
|
||
| The same constraint exists at the GTIR level: the ITIR type inference also stores a single type per node (and asserts on conflicting re-assignment), so the single `map_tuple` lambda used to lower comprehensions over variable-length tuples can only have one function type. For variable-length iterables heterogeneity cannot occur in the first place, since `VarArgType` describes all elements with a single element type. Rejecting heterogeneous iterables in the FOAST type deduction just surfaces the error earliest, with a source location. | ||
|
|
||
| ## Decision | ||
|
|
||
| Only homogeneous iterables are supported, both fixed-length and variable-length. Heterogeneous ones are rejected in the type deduction. E.g., with `a`, `b`, `c`, `d` of equal type: | ||
|
|
||
| ```python | ||
| tuple(2.0 * el for el in (a, b)) # supported | ||
| tuple(2.0 * el for el in (a(V2E), b(V2E))) # supported | ||
| tuple(local_el + el for local_el, el in ((a(V2E), b), (c(V2E), d))) # supported | ||
| tuple(2.0 * el for el in (a(V2E), b)) # rejected: local vs. non-local element | ||
| ``` | ||
|
|
||
| Note that homogeneity applies to the iterable's elements as a whole: in the third example each element is a pair of a local and a non-local field, but all elements share that same tuple type, so each target symbol still has a single consistent type. | ||
|
|
||
| ## Consequences | ||
|
|
||
| - Typing and lowering stay simple: the element expression is visited once, with one type per node. | ||
| - Computations over differently-typed elements cannot be written as a comprehension; they must be spelled out per element. | ||
| - The restriction could be lifted for fixed-length iterables by typing the mapper generically: the target symbol gets a type variable bounded by the valid element types, so a single type per node still suffices during type deduction. After `map_tuple` expansion the mapper is instantiated once per element, and each instance can then be specialized to its concrete element type. This is possible as a follow-up without breaking existing code, since it only widens the set of accepted programs. For variable-length iterables there is nothing to lift: heterogeneity cannot occur, as `VarArgType` has a single element type by construction. | ||
|
|
||
| ## References | ||
|
|
||
| - PR [#2833](https://github.com/GridTools/gt4py/pull/2833) (tuple comprehension support) |
This file contains hidden or 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 hidden or 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 hidden or 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 hidden or 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 hidden or 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 hidden or 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 hidden or 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.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Uh oh!
There was an error while loading. Please reload this page.