I made a wiki page about the general architecture of Coq user interfaces. It was useful for me to better understand the articulations between different approaches and I hope it will be useful for others. Don't hesitate to comment, amend, refine, ...
Doing this summary leads me to feel that we should eventually be able to arrive to a quite modular approach to user interfaces based on a standardized proof-assistant-oriented extension of LSP.
nice summary, but I'm missing the really low level interfaces like Serlib and PyCoq. For some interaction, just consuming/manipulating Coq data structures is essential (such as looking at token level to do formatting)
Thanks for being supportive.
I'm missing the really low level interfaces like Serlib and PyCoq
I have no idea. I'll ask around to understand better where to put them (or maybe someone reading this knows).
maybe one way to think about it is that Coq has both "user" and "programming" interfaces, and many of them overlap in strange ways
for example coqtop
is I guess a user interface of sorts, but arguably is used programmatically by ProofGeneral
coq-lsp can also be used programmatically to achieve some of the same objectives as with SerAPI / PyCoq.
@Pierre Courtieu: you added Ltac debugger to the list of PG features. Do you have any link to the documentation for this feature? How does it compare to the CoqIDE Ltac debugger? Should the latter be qualified as "Visual Ltac debugger" to distinguish?
@Théo Zimmermann let me have a look at coqide debug mode before I answer :-)
https://coq.inria.fr/refman/practical-tools/coqide.html#debugger
and actually pg debugging mode seems currently broken...
because of a change in debugger messaging.
OK let us remove "Ltac Debugger" for pg :-)
Could it be related to the introduction of the visual debugger in CoqIDE in fact? Feel free to open an issue and to tag Jim.
I don't know. I will investigate. Anyway the graphical breakpoints of coqide is much nicer.
Théo Zimmermann said:
coq-lsp can also be used programmatically to achieve some of the same objectives as with SerAPI / PyCoq.
Indeed there is now a fcc
compiler that will be in the upcoming release which removes the need to spawn a lsp client, also it is extensible in OCaml and Python (which covers a lot of use cases that required hacks to SerAPI
)
Could finally decode it: fcc = Flèche Coq Compiler, that is an executable to access most of the features of Flèche on the command line without having to communicate over LSP.
I did not get what it means to be "extensible in OCaml and Python" though.
Happy to find a better name (see issue https://github.com/ejgallego/coq-lsp/issues/472 )
Extensible means that you can write plugins in both OCaml and Python, see example plugin at https://github.com/ejgallego/coq-lsp/tree/main/plugins/simple
A lot more work on documentation in required indeed
IMHO you shouldn't care about the name before the question of the renaming of Coq itself is concluded.
@Théo Zimmermann indeed that is one of the reasons I picked fcc
for now as interim name, but SerAPI was also an interim name and it stuck (and not a very good one IMHO)
Last updated: Oct 13 2024 at 01:02 UTC