Disable recursive priorities #1600
Merged
Conversation
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
Recursive priorites were added pre-RFC005, where their semantics was straightforward. Because metadata could appear anywhere, recursive priorities (or also called push priorities) just amounted to have a primop that pushed the priorities down a term, in one lazy step. Since RFC005, this isn't possible anymore, because only record field can hold metadata. It's now much more intricate to implement, because when encountering a `rec force` at the field level, we first need to know if there's any value able to receive it underneath this field to know if we should attach it to the field or no. To know that, we might need to evaluate the field first, and then decide. Before sorting out both the new semantics and implementation, this commit disable the syntax (but keep the rest of the machinery) from 1.2.0 so that we can do some design before shipping new recursive priorities or scraping them entirely. Recursive priorities were undocumented, and should have been disabled from 1.0.0, so it's not considered a breaking change.
vkleen
approved these changes
Sep 13, 2023
suimong
pushed a commit
to suimong/nickel
that referenced
this pull request
Sep 17, 2023
Recursive priorites were added pre-RFC005, where their semantics was straightforward. Because metadata could appear anywhere, recursive priorities (or also called push priorities) just amounted to have a primop that pushed the priorities down a term, in one lazy step. Since RFC005, this isn't possible anymore, because only record field can hold metadata. It's now much more intricate to implement, because when encountering a `rec force` at the field level, we first need to know if there's any value able to receive it underneath this field to know if we should attach it to the field or no. To know that, we might need to evaluate the field first, and then decide. Before sorting out both the new semantics and implementation, this commit disable the syntax (but keep the rest of the machinery) from 1.2.0 so that we can do some design before shipping new recursive priorities or scraping them entirely. Recursive priorities were undocumented, and should have been disabled from 1.0.0, so it's not considered a breaking change.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Closes #1581.
Recursive priorities were added pre-RFC005, where their semantics was straightforward. Because metadata could appear anywhere, recursive priorities (or also called push priorities) just amounted to have a primop that pushed the priorities down a term, in one lazy step.
Since RFC005, this isn't possible anymore, because only record fields can hold metadata. It's now more intricate to implement, because when encountering a
rec forceat the field level, we first need to know if there's any value able to receive it underneath the field to know if we should attach it to the field or no. To know that, we need to evaluate the field first, and then decide.Before sorting out both a new semantics and implementation, this commit disables the syntax (but keep the rest of the machinery) for 1.2.0 so that we can do some design before shipping new recursive priorities or scraping them entirely. Recursive priorities were undocumented, and should have been disabled from 1.0.0, so it's not considered a breaking change.