Skip to content
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

Do not evaluate types away #1954

Merged
merged 1 commit into from
Jun 12, 2024
Merged

Do not evaluate types away #1954

merged 1 commit into from
Jun 12, 2024

Conversation

yannham
Copy link
Member

@yannham yannham commented Jun 11, 2024

Before this change, types used in a term would be evaluated away to their corresponding contract (a function) automatically. Note that the only meaningful usage of types right now is to pass them as argument for std.contract.apply.

This eager conversion loses information; either for error messages (for example, using a type in the wrong place will complain that something has type "function" and might point to inside Nickel internals instead of the actual user-written type). Moreover, in preparation for boolean combinators for contracts, we want to be able to remember the original form of a type as much as possible.

Finally, it might be useful for users to introspect types as well, for example to implement custom contract combinators.

For all these reasons, and because there's no apparent drawback, this commit makes type normal values, that aren't evaluated further. A new case in the %contrat/apply% primop simply performs the conversion to contract lazily, once they are actually applied, instead of where they are defined. %typeof% and std.typeof are updated accordingly with the new 'Type tag.

Related: #1466, #1460

Before this change, types used in a term would be evaluated away to
their corresponding contract (a function) automatically. Note that the
only meaningful usage of types right now is to pass them as argument for
`std.contract.apply`.

This eager conversion loses information; either for error messages (for
example, using a type in the wrong place will complain that something
has type "function" and might point to inside Nickel internals instead
of the actual user-written type). Moreover, in preparation for boolean
combinators for contracts, we want to be able to remember the original
form of a type as much as possible.

Finally, it might be useful for users to introspect types as well, for
example to implement custom contract combinators.

For all these reasons, and because there's no apparent drawback, this
commit makes type normal values, that aren't evaluated further. A new
case in the `%contrat/apply%` primop simply performs the conversion to
contract lazily, once they are actually applied, instead of where they
are defined. `%typeof%` and `std.typeof` are updated accordingly with
the new `'Type` tag.
@yannham yannham requested review from jneem and vkleen June 11, 2024 15:13
@github-actions github-actions bot temporarily deployed to pull request June 11, 2024 15:16 Inactive
@yannham yannham added this pull request to the merge queue Jun 12, 2024
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Jun 12, 2024
@yannham yannham added this pull request to the merge queue Jun 12, 2024
Merged via the queue into master with commit c7fc4a1 Jun 12, 2024
5 checks passed
@yannham yannham deleted the task/dont-evaluate-types branch June 12, 2024 08:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants