
Coq 8.6 is out - infruset
https://coq.inria.fr/news/134.html
======
tombert
I've been looking for an excuse to play with Coq ( _cough_ ) for awhile now. A
new release is as good an excuse as any I suppose.

Does anyone know how this compares to something like Idris?

~~~
chm
FWIW you would pronounce "Coq" much more like "kuhk" than "cock", if that
makes sense. But that depends on the accent :)

~~~
staticassertion
I think it's actually "coke", isn't it?

~~~
jrmyp
In French "coq" is \kɔk\, compared in to "cock" and "coke" which are \ˈkɑːk\
and \koʊk\ in English.

It would be closer to "caught" \kɔːt\ with a short vowel and a \k\ sound at
the end.

~~~
pasquinelli
maybe i've got a weird accent, but "caught" with a "k" replacing the "t" is
how i pronounce cock.

~~~
jasonmp85
"Caught" is a terrible word to use for any examples here. The parent's IPA is
handy, but betrays the fact that they actually distinguish between cot and
caught, something that by this point is pretty much a regionalism:
[https://en.wikipedia.org/wiki/Phonological_history_of_Englis...](https://en.wikipedia.org/wiki/Phonological_history_of_English_low_back_vowels#Cot.E2.80.93caught_merger)

EDIT: I may have a slight bias as a "General American" user, but I just
noticed the parent actually also includes a length suprasegmental modifier,
which probably means they're a Received Pronunciation English speaker, or
copy-pasted the IPA from somewhere :-D. At any rate, my point that "it sounds
like the vowel in 'caught' is pretty ambiguous" still stands.

------
primodemus
Nice book that uses Coq:
[https://www.cis.upenn.edu/~bcpierce/sf/current/index.html](https://www.cis.upenn.edu/~bcpierce/sf/current/index.html)

------
pron
Has anyone here ever used Coq to verify a non-trivial piece of production
software? What was the experience like? (I have experience with other formal
methods, a good amount of TLA+ and tiny a bit of Alloy and Why3, but I've
never used Coq)

~~~
nonsens3
Sorry for the offtopic, but have you ever used TLA+ to verify a non-trivial
piece of production software? I recently found out about it, and was wondering
if there are good public use-case details on it! I know Amazon has used it for
some of their production systems, such as S3, and DynamoDB, but couldn't find
many details.

~~~
martincmartin
This is the one paper I know of: [http://research.microsoft.com/en-
us/um/people/lamport/tla/am...](http://research.microsoft.com/en-
us/um/people/lamport/tla/amazon.html)

I know of some small scale use at Facebook (where I work), where it has been
used to verify a non-trivial protocol under various combinations of failures.

~~~
technion
I've been referred to this paper before when asking this question.

Whilst it does discuss that Amazon used TLA+ in nontrivial circumstances, it's
still a long mental leap to me to get to "TLA+ for AWS S3 looked like this,
and this is the sort of bug it helped quash".

It'd be great to see some of that sort of thing.

~~~
pron
If you want to see what TLA+ specifications of distributed systems look like,
there's this lecture series, each on a different distributed algorithm:
[https://github.com/tlaplus/DrTLAPlus](https://github.com/tlaplus/DrTLAPlus)

The kind of bugs you find when verifying distributed systems is, if this
machine was in that state and that message was in transit, and then the other
machine failed, then data was lost".

Basically, because formal verification of this kind ensures the specification
is correct, it _will_ find any kind of bug there is. But it's those bugs that
are either a result of a severe flaw in the design, or bugs that would be hard
to find in testing but their results may be serious, that make this
worthwhile.

------
ah312
I guess this is as good a place as any, but has anyone used Microsoft's Lean
before ([http://leanprover.github.io/](http://leanprover.github.io/))? How
does it compare to Coq?

I'm really interested in getting started with formal verification, but I have
a more "engineering" background and don't really know where to start. Coq,
Isabelle, Lean... There's quite a few of these tools out there!

~~~
pron
Most of the tools you mentioned are general theorem provers. They can be used
for formal verification of software, but they are mostly research tools.
Isabelle is probably the most production quality of those you mention.
Industrial-grade formal verification tools -- designed for use by engineers
and made to handle larger, more complex software -- include Z, TLA+, B-Method,
Why3, SPIN, SCADE. My personal favorite is TLA+. You can start verifying real
software in TLA+ in the same amount of time it would take you to get through
the first one or two chapters in a book about Coq, and the size and complexity
of systems you can affordably specify and verify are larger than you could
ever hope to do in Coq.

If you absolutely must have end-to-end verification, namely you must verify
that global program correctness properties are preserved all the way to the
machine code, then you should probably use SCADE if you're writing embedded
real-time software; otherwise, consider Isabelle.

~~~
sheepmullet
Have you used Z? How does it compare to TLA+?

I'm thinking of trying out TLA+ this holidays to spec a couple of algorithms
at work.

~~~
pron
> Have you used Z? How does it compare to TLA+?

I haven't used it but I've seen some examples of it. In many ways it is
similar to TLA+, and Lamport says it's a nice, mathematical language. From an
aesthetic point of view, it is less elegant: it has many more built-in
concepts. From a pragmatic point of view, I think it does not support
concurrency at all. Before creating TLA+, Lamport had intended to add TLA to Z
for concurrency. This was the result: [https://research.microsoft.com/en-
us/um/people/lamport/pubs/...](https://research.microsoft.com/en-
us/um/people/lamport/pubs/pubs.html#tlz)

Anyway, here's a comparison by Lamport: [https://research.microsoft.com/en-
us/um/people/lamport/pubs/...](https://research.microsoft.com/en-
us/um/people/lamport/pubs/spec-book-chap.pdf)

> I'm thinking of trying out TLA+ this holidays to spec a couple of algorithms
> at work.

Cool. Apart from being very useful, it's a lot of fun.

------
LeanderK
I am currently hearing "formal Systems" at my university and that got me
interested a bit. Can somebody comment why in practice it's so hard? In and
ideal world I would image that certain languages are easier to prove (haskell
vs C) and with the right tooling it should be able to prove many things
quickly. Some things will always remain hard, but right now i don't see formal
proofs of programs at all (i only hear some rumours that some companies use it
at some small scale). So what's holding it back from being practical? Not
enough engineer Man-power? Or is our theoretical understanding still not
developed enough?

~~~
tom_mellior
> In and ideal world I would image that certain languages are easier to prove
> (haskell vs C)

It is. That's why Coq is a pure functional language, rather more like Haskell
than like C.

> and with the right tooling it should be able to prove many things quickly

Yes, this should be possible, and it _is_ possible.

If you mean you want it to be automated: Isabelle/HOL has more automation than
Coq. For many simple things, it suffices to tell Isabelle, essentially, to
perform induction on a given variable and from that to try to find a proof
automatically. It builds on several external provers to implement this.

What is difficult is for the system to know which existing lemmas to reuse and
how to combine them. It's a bit like your math homework, except that these
systems know more lemmas (i.e., have a larger search space) and are not always
good at ranking them by relevance.

> right now i don't see formal proofs of programs at all (i only hear some
> rumours that some companies use it at some small scale)

Look up SEL4 and CompCert for a start.

~~~
LeanderK
OK, so if i want to build a program that proves my haskell code with a similar
ease as using quickcheck[0] it would be possible, its just that nobody has
done it yet and not that i would be nearly useless because i wouldn't be able
to prove the most basic every-day functions.

I would guess an database of previously proved lemmas for all the used
libraries would help, so that you don't have to recompute everything.

[0] quickcheck is an awesome library that generates unit-tests for specified
properties (like: "for all lists s: length(sort(s)) = length(s)", i would then
just generate a few hundred lists and check whether the property got violated)

~~~
bbcbasic
Liquid Haskell is worth a look

~~~
LeanderK
i was not aware of what's going on with Liquid Haskell! This dissertation[0]
just came out and looks like to be exactly what i had in mind!

[0]
[http://goto.ucsd.edu/~nvazou/thesis/main.pdf](http://goto.ucsd.edu/~nvazou/thesis/main.pdf)

------
ohitsdom
The first link in the post is a 404 for me:
[https://coq.inria.fr/coq-86](https://coq.inria.fr/coq-86)

------
mrcactu5
any reason to prefer Coq to Agda? And remind me what is the advantage over
Haskell?

~~~
wyager
Coq and Agda are both based on dependent types, but Agda is more of an in-
progress research language whereas Coq is currently quite useful for doing
proofs in practice.

Haskell doesn't have full support for dependent types (yet). The Haskell
community is very cautious with adding features that make type inference
undecidable (like dependent types), so what people do is gradually add type
system features onto GHC and then gate them behind feature flags. So you can
do _some_ of the things you can do in Agda in Haskell (like GADTs, kind
promotion, limited type functions, etc.) but not everything.

The advantage of Haskell's conservative approach is that it's actually very
useful for writing programs, whereas Coq is only really meant for writing
proofs and Agda is more of a research testbed than a production language.

~~~
mitchty
Even when Haskell gets dependent types, they won't be quite as powerful as
what agda/coq/idris have with the termination checks I believe. Which is fine,
I don't think that many people want to program via proofs for everything.

I'd say Idris is the closest to a useful general purpose programming language
with proofs. At least that I've found so far, unless isabelle is? Not used it
just came across it a while back and have to have a look.
[https://isabelle.in.tum.de/overview.html](https://isabelle.in.tum.de/overview.html)

------
iagooar
Is there a good book about more advanced usage of coq?

~~~
rhaps0dy
Just say "cock", with a straight face, not laughing and serious, and people
will not laugh. People will know it's the proof assistant.

Same when saying "Hoare logic".

~~~
steego
Ignore the children. Coq is a fantastic tool!

It's unfortunate people think of Coq as an academic language. I really think
it's something more people should pull out at the workspace and not confine it
to college experimentation.

However the academic side of it is pretty slick. First, it's amazing how a few
dozen lines of Coq can help explain the ins-and-outs of Hoare logic.
([https://www.cis.upenn.edu/~bcpierce/sf/current/HoareAsLogic....](https://www.cis.upenn.edu/~bcpierce/sf/current/HoareAsLogic.html)).
If you're into some really heady stuff and into homotopic types, the HoTT/Coq
community has been explosive lately. While it's a great community, they can be
a little particular when it comes to pull requests. Don't take it personally,

Writing secure software will become a huge priority over the next few decades.
There are many tools out there to create verifiable software, but I suspect
there will always an opening for someone who can crank out rock solid Coq.

