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

RFC: Realizalbe constants error handling #5944

Open
nomeata opened this issue Nov 4, 2024 · 3 comments
Open

RFC: Realizalbe constants error handling #5944

nomeata opened this issue Nov 4, 2024 · 3 comments
Labels
P-medium We may work on this issue if we find the time RFC Request for comments

Comments

@nomeata
Copy link
Collaborator

nomeata commented Nov 4, 2024

Context

We have a few definitions that are lazily realized when they are actually used (equational theorems, functional induction theorem, the splitter, and there are more to come). For some of them the construction can fail, and it seems unlikely that we’ll make all of them work always anytime soon.

Status quo

If the process then every attempt to use the constant will run the process again. Log messages and exceptions are shown, in addition to a “unknown constant 'foo.bar'” error message.

Problem

This is not great because the work is repeated unnecessarily (e.g. imagine a try split in a tactic, trying to create the splitter over and over again), and the error messages are likely confusing to the user if the user is not aware of how realizable constants work.

This is also the reason why using #check foo.induct shows error messages twice, because #check happens to try to elaborate the name in different ways, and each attempts a realization.

Ideally, the visible behavior is as close as possible to the mental model of the users, which is that these realizable constants either had existed all along, or simply don’t exist.

Proposal

To get closer to that ideal, I suggest

  • To introduce a persistent env extension failedRealizations that stores the name of realizable constants that failed to realize. This is used to avoid trying to futilely realize a constant over and over again.
  • Log and error messages from the generation process are hidden by default (so that to the user it looks as if the constant is there or not.)
  • With set_option debug.realization true the messages are shown.

Variants

I thought about storing the log and error messages in the env extension so that it can be queried with a #print realization_errors foo.induct or so, but seems overkill. Maybe for debugging we’ll need a way to force realization even if there is an entry in failedRealizations.

@nomeata nomeata added the RFC Request for comments label Nov 4, 2024
@Kha
Copy link
Member

Kha commented Nov 8, 2024

#5864 should ensure error messages are printed at most once, all other elaboration threads will see a sorried-out constant. I don't think it's a good idea to hide error messages by default, I'd rather annotate them with the proper context.

@nomeata
Copy link
Collaborator Author

nomeata commented Nov 8, 2024

(Let’s pause this discussion until parallelism lands)

@leanprover-bot leanprover-bot added the P-medium We may work on this issue if we find the time label Nov 8, 2024
@nomeata
Copy link
Collaborator Author

nomeata commented Nov 15, 2024

Related: #6066, #6065, #6067. Worth looking at them together.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P-medium We may work on this issue if we find the time RFC Request for comments
Projects
None yet
Development

No branches or pull requests

3 participants