coq VS coc.nvim

The page summarizing the considered new names and their pros/cons is interesting: https://github.com/coq/coq/wiki/Alternative-names

Naming is hard...

Are those more important than, say:

- Proven with Coq, a formal proof management system: https://coq.inria.fr/

See in the real world: https://aws.amazon.com/security/provable-security/

And check out Computer-Aided Verification (CAV).

To be ruthlessly, uselessly pedantic - after all, we're mathematicians - there's reasonable definitions of "academic" where logical unsoundness is still academic if it never interfered with the reasoning behind any proofs of interest ;)

But: so long as we're accepting that unsoundness in your checker or its underlying theory are intrinsically deal breakers, there's definitely a long history of this, perhaps more somewhat more relevant than the HM example, since no proof checkers of note, AFAIK, have incorporated mutation into their type theory.

For one thing, the implementation can very easily have bugs. Coq itself certainly has had soundness bugs occasionally [0]. I'm sure Agda, Lean, Idris, etc. have too, but I've followed them less closely.

But even the underlying mathematics have been tricky. Girard's Paradox broke Martin-Löf's type theory, which is why in these dependently typed proof assistants you have to deal with the bizarre "Tower of Universes"; and Girard's Paradox is an analogue of Russell's Paradox which broke more naive set theories. And then Russell himself and his system of universal mathematics was very famously struck down by Gödel.

But we've definitely gotten it right this time...

[0] https://github.com/coq/coq/issues/4294

Dafny and Whiley are two examples with explicit verification support. Idris and other dependently typed languages should all be rich enough to express the required predicate but might not necessarily be able to accept a reasonable implementation as proof. Isabelle, Lean, Coq, and other theorem provers definitely can express the capability but aren't going to churn out much in the way of executable programs; they're more useful to guide an implementation in a more practical functional language but then the proof is separated from the implementation, and you could also use tools like TLA+.

https://dafny.org/

https://whiley.org/

https://www.idris-lang.org/

https://isabelle.in.tum.de/

https://leanprover.github.io/

https://coq.inria.fr/

http://lamport.azurewebsites.net/tla/tla.html

Still, there are many useful tools based on these ideas, used by programmers and mathematicians alike. What you describe sounds rather like Datalog (e.g. Soufflé Datalog), where you supply some rules and an initial fact, and the system repeatedly expands out the set of facts until nothing new can be derived. (This has to be finite, if you want to get anywhere.) In Prolog (e.g. SWI Prolog) you also supply a set of rules and facts, but instead of a fact as your starting point, you give a query containing some unknown variables, and the system tries to find an assignment of the variables that proves the query. And finally there is a rich array of theorem provers and proof assistants such as Agda, Coq, Lean, and Twelf, which can all be used to help check your reasoning or explore new ideas.

What ever happened to the effort [1] to rename Coq in order to make it less offensive? There were a number of excellent proposals [2] that seemed to die on the vine.

[1] https://github.com/coq/coq/wiki/Alternative-names

[2] https://github.com/coq/coq/wiki/Alternative-names#c%E1%B5%A3...

Information about the Coq proof assistant: https://coq.inria.fr/ , https://en.wikipedia.org/wiki/Coq

This type of thing can help you formally verify code.

So, if your proof is correct, and your description of the (language/CPU) is correct, you can prove the code does what you think it does.

Formal proof systems are still growing up, though, and they are still pretty hard to use. See Coq for an introduction: https://coq.inria.fr/

Most of the proof assistants out there: Lean, Coq, Dafny, Isabelle, F*, Idris 2, and Agda. And the main concepts are dependent types, Homotopy Type Theory AKA HoTT, and Category Theory. Warning: HoTT and Category Theory are really dense, you're going to really need to research them.

As well as its own plugins Vim/NeoVim can use VSCode's LSPs, DAPs and extensions either directly or via plugins like CoC[1] and Mason[2].

I would be surprised if emacs couldn't do the same.

1. https://github.com/neoclide/coc.nvim

The most famous TypeScript one probably is coc.nvim

It is flatly the wrong mindset to think of vim as an IDE. vim is a code editor: get in, make change, get out. Consider vim koans, which are a fun little read. You can throw coc.nvim at Neovim, along with a few other bits to give you a Good Enough setup, but vim isn't and will never be an IDE.

I just did a fresh reinstall of CoC, on a newer version of Neovim. I'm now seeing something I hadn't seen before, which CoC calls "inlay hints". They look like this:

I'm currently on an old setup (using coc and polyglot) and nvim v0.6.1. I'll be updating to a more modern setup within next year, using the native lsp and building nvim more frequently. But that's not today.

coc.nvim

There are some plugins which have the best documentations I have ever seen, but you need to read it from the Vim.

Example of coc.nvim: https://github.com/neoclide/coc.nvim/blob/master/doc/coc.txt

Actually you can with coc.nvim & coc-sh. So long as shellcheck is also installed and in PATH, it'll integrate with coc/vim just fine.

When you install an extension it runs an npm install or yarn, iirc, which is going to be problematic for you being offline. I was going to say you could copy that ~/.config/coc folder directly to the other machine but yeah, Windows, no idea. You see here https://github.com/neoclide/coc.nvim/wiki/Using-coc-extensions

You can try https://github.com/neoclide/coc.nvim, the pre-requisite is to install nodeJS, then to install all the languages LSP. This works for me for Angular, Rust, JavaScript, Vimscript, etc