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 raw term production #3829

Closed
wants to merge 5 commits into from
Closed

Add raw term production #3829

wants to merge 5 commits into from

Conversation

Baltoli
Copy link
Contributor

@Baltoli Baltoli commented Nov 27, 2023

The LLVM backend code that emits binary KORE terms into a proof trace wraps terms that are not represented as symbols at runtime in an injection into KItem to allow them to be serialized using the code-generated recursion scheme used elsewhere in the backend.

However, doing so is not sound (see runtimeverification/llvm-backend#904 for the full context). The additional injection changes the semantics of the serialized terms, and it is ambiguous whether client parser code should strip the injection from terms it reads from the trace.

The solution to this problem that I propose in this PR is to add a symbol to the K standard library whose only purpose is to signal "the term under this symbol is an injection into KItem that should be stripped when parsing a trace"; I have also implemented a small check that verifies user code does not attempt to write rules using this symbol.

Subsequent follow-up changes will be required to fully implement this solution:

  • Change to the LLVM backend proof trace code to emit #rawTerm instead of injections, along with a version bump for the format.
  • Updates / additions to the Pyk bindings to optionally detect and strip these terms when deserializing binary KORE to patterns.

There may be a better way to implement something equivalent to these changes; I'm open to suggestions!

@Baltoli Baltoli marked this pull request as draft November 27, 2023 14:14
Copy link
Collaborator

@dwightguth dwightguth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am confused by this. What exactly is going on here?

@Baltoli
Copy link
Contributor Author

Baltoli commented Nov 27, 2023

I am confused by this. What exactly is going on here?

runtimeverification/llvm-backend#904 is the surrounding context; this isn't quite ready for a review yet. Open to suggestions for alternative implementations!

@Baltoli Baltoli requested a review from dwightguth November 27, 2023 17:41
@Baltoli Baltoli marked this pull request as ready for review November 27, 2023 17:42
@Baltoli
Copy link
Contributor Author

Baltoli commented Nov 27, 2023

Closing after discussing with @dwightguth; a better solution is to have the backend insert a symbol automatically as a preprocessing step.

@Baltoli Baltoli closed this Nov 27, 2023
rv-jenkins pushed a commit to runtimeverification/llvm-backend that referenced this pull request Nov 28, 2023
This is an alternative formulation to
runtimeverification/k#3829; that PR contains the
original context for why this change is necessary. Rather than adding a
regular symbol to the K standard library source and using a check in the
frontend to ensure that user code doesn't mention it, we directly emit a
symbol into each definition with a name that the frontend cannot
reference.

We also bump the version number for the proof hint format so that this
non-standard symbol must be explicitly accepted by the Python client
code.
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.

3 participants