Redesign Goptions API #20051

SkySkimmer · 2025-01-14T15:07:30Z

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)

ejgallego · 2025-01-14T15:21:43Z

library/goptions.mli

+
+(** 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


@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.

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"

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.

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.

What is "different synchronization option from what the standard declare_option does" mean? Isn't that "unsynchronized"?

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.

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.

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.

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.

It doesn't break the summary, declare_option isn't even where the state is declared (unlike declare_option_and_ref)

coqbot-app · 2025-01-14T18:39:42Z

🔴 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

🏃 @coqbot ci minimize will minimize the following targets: ci-fiat_crypto_legacy, ci-hott, ci-rewriter

You can also pass me a specific list of targets to minimize as arguments.

ejgallego

Having Set Foo. live outside the summary breaks the expected semantics for documents and makes the lives of document managers hard, in particular I'd break coq-lsp.

A different solution to the problem can be implemented.

SkySkimmer · 2025-01-15T09:35:03Z

Having Set Foo. live outside the summary breaks the expected semantics for documents and makes the lives of document managers hard, in particular I'd break coq-lsp.

Set isn't special, any command with state needs to synchronize it. This PR only allows hooking into Set instead of having to write some custom command.

ejgallego · 2025-01-15T10:24:54Z

Set isn't special, any command with state needs to synchronize it. This PR only allows hooking into Set instead of having to write some custom command.

Let me see again, I guess I'm misunderstanding.

ejgallego · 2025-01-15T10:54:27Z

Let me see again, I guess I'm misunderstanding.

Maybe I can understand better with this simple question:

Can the new API be used to implement a Set Foo. command that is not synchronized with the summary?

SkySkimmer · 2025-01-15T12:08:23Z

Yes

SkySkimmer · 2025-01-15T12:24:21Z

We already have plenty of APIs that let us create commands that are not synchronized, like type foo = { mutable bar : baz }
and this API does not create any state so IMO it's nothing to worry about

if it makes you feel better we can rename it declare_raw_option or some such thing

ejgallego · 2025-01-15T12:56:44Z

Thanks for confirming, I still think the API is dangerous and will eventually lead to a lot of loss of my time debugging coq-lsp. I also think it is the wrong solution to the metacoq option problem.

Moreover this would revert #481 which I'm against, and provides evidence of the potential for misuse.

Let's discuss in a call if you still want to push this solution.

SkySkimmer · 2025-01-15T13:03:12Z

I also think it is the wrong solution to the metacoq option problem.

What other solution can there even be?

gares · 2025-01-15T13:08:46Z

After reading the comment, I quite don't get the use case from metacoq.

In principle I would no be afraid if debug options were always desynchronized, they are not for regular sessions/users. But that is another discussion.

SkySkimmer · 2025-01-15T13:15:43Z

The metacoq solution is to use that API to have separate synchronization from the option declaration (Foo Debug has no state of its own and reads/writes from Foo Debug Verbosity, which is synchronized)
having unsynchronized state is probably a bad idea but having APIs which don't enforce a particular synchronization is useful

gares · 2025-01-15T14:54:55Z

Hum, it seems to me that they want to use Set Debug "metacoq" instead of a custom MetaCoq Debug that would be allowed to do anything without changing Coq.

Am I right?

SkySkimmer · 2025-01-16T13:20:41Z

Set Debug isn't great when you want to have verbosity levels (you have to create a debug flag for each level so it ends up looking like Set Debug "metacoq,metacoq-verbose,metacoq-more-verbose" instead of Set Metacoq Debug Verbosity 3

ejgallego · 2025-01-17T14:44:09Z

The metacoq solution is to use that API to have separate synchronization from the option declaration (Foo Debug has no state of its own and reads/writes from Foo Debug Verbosity, which is synchronized)

Why can't just metacoq get rid of Foo Debug and have Set Debug Verbosity 0 to disable debug? IMHO the tradeoff here is bad, moreover for something that is internal. If we really want this, we can introduce a new type of option, or options groups, etc... I can see a few ways.

Actually having (a properly synchronized) option type for a debug switch may not be a bad idea.

having unsynchronized state is probably a bad idea but having APIs which don't enforce a particular synchronization is useful

I agree that it is useful, on the other hand it creates many problems and headaches for the upper layers. There are many examples of something being useful (allowing a pointer to be null comes to my head) but that creates trouble too.

ejgallego · 2025-01-17T14:44:51Z

Actually having (a properly synchronized) option type for a debug switch may not be a bad idea.

Something like declare_option_with_levels min max group that has C-like semantics 0 = false

SkySkimmer · 2025-01-22T13:25:34Z

Stopped exposing a unsynchronized option api
I'll put it back if I have a present use for it I guess

ejgallego

LGTM thanks.

coqbot-app · 2025-01-22T16:55:40Z

🔴 CI failures at commit ec9b66a without any failure in the test-suite

✔️ Corresponding jobs for the base commit 8d8ece3 succeeded

❔ Ask me to try to extract minimal test cases that can be added to the test-suite

🏃 @coqbot ci minimize will minimize the following targets: ci-coq_performance_tests, ci-engine_bench, ci-fiat_crypto_legacy, ci-hott, ci-neural_net_interp, ci-rewriter, ci-stdlib_test

You can also pass me a specific list of targets to minimize as arguments.

- use GADT to control the type of the value - deprecate "Set ... Append" command, instead appending is a behaviour of the given option (currently Warnings and Debug)

SkySkimmer added kind: redesign The same functionality is being re-implemented in a different way. request: full CI Use this label when you want your next push to trigger a full CI. labels Jan 14, 2025

SkySkimmer added this to the 9.1+rc1 milestone Jan 14, 2025

SkySkimmer requested review from a team as code owners January 14, 2025 15:07

coqbot-app bot removed the request: full CI Use this label when you want your next push to trigger a full CI. label Jan 14, 2025

ejgallego reviewed Jan 14, 2025

View reviewed changes

ejgallego requested changes Jan 15, 2025

View reviewed changes

SkySkimmer added the request: full CI Use this label when you want your next push to trigger a full CI. label Jan 16, 2025

SkySkimmer force-pushed the goptions-redesign branch from a5148e7 to e68c766 Compare January 16, 2025 13:21

coqbot-app bot removed the request: full CI Use this label when you want your next push to trigger a full CI. label Jan 16, 2025

SkySkimmer added the request: full CI Use this label when you want your next push to trigger a full CI. label Jan 22, 2025

SkySkimmer force-pushed the goptions-redesign branch from e68c766 to ec9b66a Compare January 22, 2025 13:24

SkySkimmer requested a review from ejgallego January 22, 2025 13:24

coqbot-app bot removed the request: full CI Use this label when you want your next push to trigger a full CI. label Jan 22, 2025

ejgallego approved these changes Jan 22, 2025

View reviewed changes

SkySkimmer added needs: overlay This is breaking external developments we track in CI. request: full CI Use this label when you want your next push to trigger a full CI. and removed needs: overlay This is breaking external developments we track in CI. labels Jan 22, 2025

SkySkimmer added a commit to SkySkimmer/paramcoq that referenced this pull request Jan 28, 2025

Adapt to coq/coq#20051 (goptions API change)

03ac2e2

Redesign Goptions API

f1cc58d

- use GADT to control the type of the value - deprecate "Set ... Append" command, instead appending is a behaviour of the given option (currently Warnings and Debug)

SkySkimmer force-pushed the goptions-redesign branch from ec9b66a to f1cc58d Compare January 28, 2025 12:11

SkySkimmer requested review from a team as code owners January 28, 2025 12:11

coqbot-app bot removed the request: full CI Use this label when you want your next push to trigger a full CI. label Jan 28, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Redesign Goptions API #20051

Redesign Goptions API #20051

SkySkimmer commented Jan 14, 2025 •

edited

Loading

ejgallego Jan 14, 2025

SkySkimmer Jan 14, 2025

ejgallego Jan 14, 2025 •

edited

Loading

SkySkimmer Jan 14, 2025

ejgallego Jan 14, 2025

ejgallego Jan 14, 2025

jfehrle Jan 15, 2025 •

edited

Loading

SkySkimmer Jan 15, 2025

ejgallego Jan 15, 2025

SkySkimmer Jan 15, 2025

coqbot-app bot commented Jan 14, 2025

ejgallego left a comment

SkySkimmer commented Jan 15, 2025

ejgallego commented Jan 15, 2025 •

edited

Loading

ejgallego commented Jan 15, 2025

SkySkimmer commented Jan 15, 2025

SkySkimmer commented Jan 15, 2025

ejgallego commented Jan 15, 2025 •

edited

Loading

SkySkimmer commented Jan 15, 2025

gares commented Jan 15, 2025

SkySkimmer commented Jan 15, 2025

gares commented Jan 15, 2025

SkySkimmer commented Jan 16, 2025

ejgallego commented Jan 17, 2025

ejgallego commented Jan 17, 2025 •

edited

Loading

SkySkimmer commented Jan 22, 2025 •

edited

Loading

ejgallego left a comment

coqbot-app bot commented Jan 22, 2025

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Redesign Goptions API #20051

Are you sure you want to change the base?

Redesign Goptions API #20051

Conversation

SkySkimmer commented Jan 14, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ejgallego Jan 14, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jfehrle Jan 15, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

coqbot-app bot commented Jan 14, 2025

ejgallego left a comment

Choose a reason for hiding this comment

SkySkimmer commented Jan 15, 2025

ejgallego commented Jan 15, 2025 • edited Loading

ejgallego commented Jan 15, 2025

SkySkimmer commented Jan 15, 2025

SkySkimmer commented Jan 15, 2025

ejgallego commented Jan 15, 2025 • edited Loading

SkySkimmer commented Jan 15, 2025

gares commented Jan 15, 2025

SkySkimmer commented Jan 15, 2025

gares commented Jan 15, 2025

SkySkimmer commented Jan 16, 2025

ejgallego commented Jan 17, 2025

ejgallego commented Jan 17, 2025 • edited Loading

SkySkimmer commented Jan 22, 2025 • edited Loading

ejgallego left a comment

Choose a reason for hiding this comment

coqbot-app bot commented Jan 22, 2025

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

SkySkimmer commented Jan 14, 2025 •

edited

Loading

ejgallego Jan 14, 2025 •

edited

Loading

jfehrle Jan 15, 2025 •

edited

Loading

ejgallego commented Jan 15, 2025 •

edited

Loading

ejgallego commented Jan 15, 2025 •

edited

Loading

ejgallego commented Jan 17, 2025 •

edited

Loading

SkySkimmer commented Jan 22, 2025 •

edited

Loading