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

Add dedicated node and constructor for general custom contracts #1964

Merged
merged 7 commits into from
Jun 24, 2024

Conversation

yannham
Copy link
Member

@yannham yannham commented Jun 18, 2024

Continue to address #1466.

After introducing a special AST node and constructor for contracts built from a predicate in #1955, this PR introduces another variant for generic custom contracts. For backward compatibility reasons, we still need to support custom contracts given as naked functions, but this PR migrates examples, the stdlib and the documentation to using this new node through the std.contract.custom constructor. The only module that isn't migrated is the internals module, because it was harder to do without breaking things (it can surely be done, but it requires a bit more changes), and because those primitive contracts aren't really user-facing and thus it's less important for error messages and the like that they follow the new convention. As this PR is already sizeable, this is left for future work (or maybe we don't want to do it at all).

The documentation is updated in way that already assumes the as-of-yet nonexistent std.contract.from_validator, planned in a follow-up PR, because it was harder to pretend that it won't exist, or put differently, it would have required more effort to update the documentation once again with this new intermediate type of custom contract than to just leave a placeholder and pretend it already exists.

#1955 introduced predicates as functions, where the AST node also stores the function's parameter - the idea was to be more typed, and avoid having something else than a function lying in a CustomContract node. Unfortunately, I realized while working on this PR that custom contracts as predicates can actually also be match expressions. We could add a variant for things that are either functions or match expressions, but it starts to be verbose and to cause more code duplication. For now, I reverted to using a generic RichTerm there, where the only hypothesis is that it's a WHNF that can be applied to some arguments.

@github-actions github-actions bot temporarily deployed to pull request June 18, 2024 16:41 Inactive
Use the previously introduced new primop in the stdlib, to migrate from
naked functions to wrapped custom contracts everywhere in the stdlib.
Introduce the new contract constructor std.contract.custom in the
manual, and make sure that this is now everywhere presented as the
official way of building custom contracts. The section on custom
contracts is also re-organized to make general custom contracts the last
section, and present it as a last resort rather than the default way of
building custom contracts. We also left some placeholder for to the
soon-to-come validators.
@github-actions github-actions bot temporarily deployed to pull request June 19, 2024 08:54 Inactive
@yannham yannham requested review from jneem and vkleen June 19, 2024 09:00
@yannham yannham marked this pull request as ready for review June 19, 2024 09:00
In a previous commit, after introducing %contract/custom%, the stdlib
was upgraded to use this new contract constructor. Doing so, in the
contract.unstable module, many `std.contract.apply` were turned into
`%contract/apply%` following the philosophy that the stdlib should avoid
indirection through other stdlib functions bit rather directly use
primops.

However, it turns out `%contract/apply%` is not equivalent to
`std.contract.apply`. The later also stack the current diagnostics,
while the former is really only performing a function-like application,
which does make a difference for error reporting - the version with
`%contract/apply%` could erase existing error reporting data.

This commit reverts those primops calls back to using
`std.contract.apply`.
@github-actions github-actions bot temporarily deployed to pull request June 19, 2024 17:29 Inactive
core/src/term/mod.rs Show resolved Hide resolved
@yannham yannham added this pull request to the merge queue Jun 24, 2024
Merged via the queue into master with commit dd0ccb1 Jun 24, 2024
5 checks passed
@yannham yannham deleted the task/contract-from-custom branch June 24, 2024 10:28
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