While investigating the following bug: https://github.com/coq-community/vscoq/issues/581, I realized that equations was using VERNAC EXTEND macros with partially applied functions in the actions. Something like derive (f c)
of type pm:Declare.OblState.t -> Declare.OblState.t
. This idiom has the consequence that f c
is evaluated at parsing time (when calling type_vernac
), instead of the expected execution phase. Question: is the plugin developer expected to write fun ~pm -> derive (f c) pm
in the action (many plugins do that, in which case everything works fine), or should we revise the coqpp
generation to eta-expand?
Cc @Pierre-Marie Pédrot
Automatically eta-expanding is a simple and efficient technique if we're 100% certain we never want side-effects in there
Since coqpp lets you embed toplevel code { here }
I think it is better to make grammar actions pure (at parse time), and force users to put side effects toplevel (if only for readability reasons)
@Enrico Tassi Just to make sure I understand properly: which solution do you suggest?
To always eta expand in coqpp.
If the user really wants some side effect he should put it into a toplevel code block.
Unfortunately, I won't have time to do it myself. Should I open a coqpp issue?
I'm also not sure technically how the eta expansion should really look like. I.e. if it depends on the classification of the action.
(note that this change is not directly related to parsing/exec separation, it is just made more obvious by it)
I'm reading the coqpp code and it seems we're already eta-expanding some pieces of code, but not all
Yes, honestly this issue rang a bell. I thought we had fixed some similar issues in the past (but not 100% sure).
I think that the idea of taking a ~pm argument directly in the body of the clause is a terrible design choice
we should not return functions precisely because they can be eta-expanded, or not
the return type should be abstract
What change introduced this btw? I thought it was the vernac extend fine-grained classification PR, but not so obvious. So it may predate it.
I think it's 54788df72ce79998ee27db362401a56bda4daceb
aka https://github.com/coq/coq/pull/11836
I think that a backwards compatible fix for 8.18 is to force coqpp to eta-expand, but ideally for 8.19 the ~pm argument should always be passed implicitly or something, like the ist one in other extensions
or we force users to wrap their functions into the typed_vernac type themselves, but this is not very backwards compatible
there is already infrastructure to wrap the body in a unit -> 'a thunk, we could just enforce the API to always thunk it for us also
I can help review a patch, but I won't have time to write it, I'm afraid. I still have to migrate the Coq website, the Coq CI and help with the VsCoq 2 & Coq 8.18 releases before next week... :)
Erf. I have to finish my share of POPL reviews, which is also a can of worms, but I can try to write a quick fix asap.
By the miracle of procrastination, here is the patch: https://github.com/coq/coq/pull/17978. I haven't tested it on the vscoq issue though.
Thanks a lot! I can take care of testing.
Last updated: Sep 15 2024 at 13:02 UTC