Redesign Goptions API #20051
Redesign Goptions API #20051
Conversation
- use GADT to control the type of the value - remove "Set ... Append" command, instead appending is a behaviour of the given option (currently Warnings and Debug) - expose API for unsynchronized options (would allow to fix the code in MetaCoq/metacoq#1123 instead of removing it)
|
|
||
| (** Helper to build synchronized options on top of [declare_unsynchronized_option]. *) | ||
| val option_object : string -> Summary.Stage.t -> ('a -> unit) -> | ||
| (option_locality * 'b, option_locality * 'a, option_locality * 'b) Libobject.object_declaration |
There was a problem hiding this comment.
@SkySkimmer , can we find a different solution for this problem?
This will break in coq-lsp / Flèche for example, and it makes impossible to properly cache command execution. Moreover, I think this is generally a footgun.
Note that we used to have this kind of "unsynchronized" options but there were removed long time ago, happy to dig the relevant issues PRs if you are curious. IIRC, all uses of them were incorrect.
There was a problem hiding this comment.
I think for the problem in MetaCoq/metacoq#1123 an unsynchronized option (but backed by the synchronized state of the other option) really is the correct solution.
I don't know what you mean by "this will break"
There was a problem hiding this comment.
I mean:
- assume an unsynchronized option "Foo." that affects for example de-elaboration.
- imagine that I have a file:
Theorem foo : ...
Set Foo.
Theorem bar : ...- now the user clicks on bar, so I print the goals there
- now the user clicks on foo, so I restore the state to print the goals there
- however the option is still set as lives outside the summary.
I do think we have a need for this kind of use cases, for example, I don't like that backtracking setting lives in the summary, however IMHO we should not expose via GOptions, see the long discussion when we removed the unsync parameter. (Basically GOptions are controlled via sentences in the document, IMO everything in the document should be synced)
What do you think? We can maybe split that change to a different PR while we discuss if you wanna get the rest merged.
There was a problem hiding this comment.
The way I think of it, declare_unsynch_option is mostly not for declaring actually unsynchronized options, rather it's for declaring options with different synchronization from what the standard declare_option does.
There was a problem hiding this comment.
What is "different synchronization option from what the standard declare_option does" mean? Isn't that "unsynchronized"?
There was a problem hiding this comment.
I'm talking about declare_unsynchronized_option indeed, sorry I placed my comment on the wrong place.
Let me re-state my worry: I'm against declare_unsynchronized_option for the reasons stated above.
Would it be too much of a trouble to split that change to a different PR and continue the discussion there?
I see declare_unsynchronized_option is not used here, and the rest of the PR seems fine.
There was a problem hiding this comment.
It does seem like quite a bad idea to break the well-established existing behavior when rolling back options. I would ask a) is this only possible way to fix this bug? and b) what are other examples of when this feature would be useful? Is it really a design flaw in metacoq? Unsynchronized options seems like something that's ripe for abuse/problems and perhaps hard to find when there is a problem.
There was a problem hiding this comment.
Would it be too much of a trouble to split that change to a different PR and continue the discussion there?
unsynchronized_option and being able to fix the metacoq bug instead of having to delete the feature is the main motivation for the PR, the other changes are mainly to make it nicer (eg not having to deal with append)
I don't know what is not clear about the need for unsynchronized_option in the comment above it.
There was a problem hiding this comment.
It is not clear why we need to introduce stuff that does break live the summary and as Jim points out will break expected document behavior.
Also it is not clear why we cannot use a different solution, like adding grouping or ordering instead of this in my opinion very problematic solution with large potential for misuse.
There was a problem hiding this comment.
It doesn't break the summary, declare_option isn't even where the state is declared (unlike declare_option_and_ref)
|
🔴 CI failures at commit a5148e7 without any failure in the test-suite ✔️ Corresponding jobs for the base commit 818d1e0 succeeded ❔ Ask me to try to extract minimal test cases that can be added to the test-suite 🏃
|
|
Let me see again, I guess I'm misunderstanding. |
use GADT to control the type of the value
remove "Set ... Append" command, instead appending is a behaviour of the given option (currently Warnings and Debug)
expose API for unsynchronized options (would allow to fix the code in Remove bugged option MetaCoq Template Monad Debug. MetaCoq/metacoq#1123 instead of removing it)