refactor[cartesian]: Separate horizontal and vertical interval parsers#2510
Merged
twicki merged 13 commits intoGridTools:mainfrom Mar 18, 2026
Merged
refactor[cartesian]: Separate horizontal and vertical interval parsers#2510twicki merged 13 commits intoGridTools:mainfrom
twicki merged 13 commits intoGridTools:mainfrom
Conversation
twicki
commented
Mar 12, 2026
| raise range_error | ||
|
|
||
| if len(args) == 2: | ||
| if any(isinstance(arg, ast.Subscript) for arg in args): |
Contributor
Author
There was a problem hiding this comment.
Note: This check is now inside the vertical parser where it belongs
|
|
||
| def test_axisinterval(self): | ||
| def definition_func(field: gtscript.Field[float]): | ||
| with computation(PARALLEL), interval(K[1:-1]): |
Contributor
Author
There was a problem hiding this comment.
note: This is the now disallowed syntax
romanc
approved these changes
Mar 13, 2026
Contributor
romanc
left a comment
romanc
left a comment
There was a problem hiding this comment.
Thank you for cleaning this up and separating concerns here. 🧹 🧹 ✨
| field_axes: Optional[Set[Literal["I", "J", "K"]]] = None, | ||
| ) -> list[int] | nodes.AbsoluteKIndex | None: | ||
| tuple_or_expr = node.slice.value if isinstance(node.slice, ast.Index) else node.slice | ||
| tuple_or_expr = node.slice |
Contributor
There was a problem hiding this comment.
Does this change have a downstream effect that tuple_or_expr is now either tuple or an expression all the time?
Contributor
Author
There was a problem hiding this comment.
No, this stems from K[1:2] previously being legal syntax.
Contributor
|
cscs-ci run |
Co-authored-by: Roman Cattaneo <romanc@users.noreply.github.com>
Contributor
Author
|
cscs-ci run |
This was referenced Mar 26, 2026
twicki
added a commit
that referenced
this pull request
Mar 27, 2026
## Series on interval-parsing (3/3) This PR is one in a series to simplify interval parsing in the front-end. This entire series was triggered, because runtime-intervals and higher dimensional fields do not interact as intended right now. So here the summary of the slate of work Current State: - The parser between horizontal and vertical intervals is shared - This leads to a lot of differentiation having to happen in the calls since what is and is not allowed is very different - There is a plethora of different syntaxes allowed for vertical intervals - With runtime-intervals now being part of the equation, differentiation became even harder. - Accessing higher-dimensional fields with `[]`-operators did trigger exceptions To tackle these problems, the following PR's are up: [2510](#2510): split the parser for the horizontal and the vertical and specialize them as appropriate [2553](#2553): fix how runtime-intervals interact with higher dimensional fields current: remove all redundant syntax to go back to a more specific language ## Description The legal syntax for regions was very bloated and allowed for multiple ways to express a single output. This PR trims this down to a more minimalistic approach. Previously allowed: - `I[0:2]` - `I[0] : I[2]` - `I[0] : I[0] + 2` - `0:2` There is no clean way to completely avoiding the axis-access syntax, as it is required to generate somewhat clean out-of-domain computations to skip by going `I[0]- LARGENUMBER`. this is why axis-access is still allowed additionally to plain offset syntax. but only to access the start and end of the domain. So this PR minimizes the syntax down to - `I[0] : I[0] + 2` - `0:2`
twicki
added a commit
that referenced
this pull request
Apr 1, 2026
…als (#2553) ## Series on interval-parsing (2/3) This PR is one in a series to simplify interval parsing in the front-end. This entire series was triggered, because runtime-intervals and higher dimensional fields do not interact as intended right now. So here the summary of the slate of work Current State: - The parser between horizontal and vertical intervals is shared - This leads to a lot of differentiation having to happen in the calls since what is and is not allowed is very different - There is a plethora of different syntaxes allowed for vertical intervals - With runtime-intervals now being part of the equation, differentiation became even harder. - Accessing higher-dimensional fields with `[]`-operators did trigger exceptions To tackle these problems, the following PR's are up: [2510](#2510): split the parser for the horizontal and the vertical and specialize them as appropriate current: fix how runtime-intervals interact with higher dimensional fields next: remove all redundant syntax to go back to a more minimalistic language ## Description Fix the behavior of runtime-intervals when accessing higher dimensional fields with an offset in the higher dimension. This additional offset was not caught properly and was always set to 0. PR 2510 disabled all higher dimensional field accesses to prevent illegal code. This PR re-introduces this feature and fixes how the access in handled to now be correct.
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Series on interval-parsing (1/3)
This PR is the first one in a series to simplify interval parsing in the front-end.
This entire series was triggered, because runtime-intervals and higher dimensional fields do not interact as intended right now. So here the summary of the slate of work
Current State:
[]-operators did trigger exceptionsTo tackle these problems, the following PR's are up:
current: split the parser for the horizontal and the vertical and specialize them as appropriate
next: remove all redundant syntax to go back to a more minimalistic language
next: fix how runtime-intervals interact with higher dimensional fields
Description
Split the parser for intervals into a horizontal and a vertical interval-parser.