
A formalization of category theory in Coq - noch
https://github.com/jwiegley/category-theory
======
solomatov
It's actually not very interesting formulation of category theory. You can't
express a category of categories, with isomorphic categories considered equal
in this way. Partially, this can be worked around if we state that everything
important preserves equivalence (i.e. if A ~ A` and B ~ B` A x B ~ A` x B`).
Though, if you want to express this in full generality, you will need Homotopy
Type Theory.

But, all in all, even formulating all this and proving theorems was a good
exercise. Good job!

~~~
xhusshjd
> You can't express a category of categories, with isomorphic categories
> considered equal in this way.

Not sure why you think that. It's a straight-forward construction within this
framework and even part of the development[1].

[1] [https://github.com/jwiegley/category-
theory/blob/master/Inst...](https://github.com/jwiegley/category-
theory/blob/master/Instance/Cat.v)

~~~
solomatov
You are right. I didn't notice compose_respects.

------
runeks
I believe this is what John Wiegley talked about in this Haskell Cast[1]
which, as I understand it, should allow translating Haskell into Coq.

I’m just beginning to understand all of this category stuff but, as far as I
can see, a Haskell function of type

    
    
        f :: a -> b
    

should be equivalent to a Coq function of type

    
    
        f :: a -> Either SomeException a
    

to account for the Hask category’s “bottom” value.

[1] [http://www.haskellcast.com/episode/013-john-wiegley-on-
categ...](http://www.haskellcast.com/episode/013-john-wiegley-on-categories-
and-compilers) (skip to “compiling to categories”)

~~~
dmytrish
How can one automatically translate any Haskell containing unbounded recursion
into Coq?

~~~
tome
Some sort of partiality monad, I presume.

------
SomeStupidPoint
Is there a good lecture series on Coq? Or maybe introductory project?

I've seen a video intro [0] and poked a little bit around the reference manual
[1], but I'm not sure what's "between" basic understanding of the commands and
being able to extract a complex verified program.

It all seems to be either the theory (which I mostly grok) or completed
projects, not a lot about the engineering details.

...Or does that just not exist?

[0]
[https://www.youtube.com/watch?v=ngM2N98ppQE](https://www.youtube.com/watch?v=ngM2N98ppQE)

[1] [https://coq.inria.fr/refman/](https://coq.inria.fr/refman/)

~~~
nickpsecurity
It's going to be hard to learn one way or another. Chlipala's Certified
Programmimg with Dependent Types is free online. Then, Software Foundations
others mentioned. Starting with lightweight stuff like Alloy or TLA+ might
help. Also, The Little Prover book teaches how provers work by letting reader
build a small one. Had some decent reviews.

~~~
solomatov
Chlipala's book is a decent one, but it's oriented towards software
verification, coq, and the use of tactics (which I would consider anti-
pattern).

Software Foundations is a good introduction to Coq and proofs, but overall is
quite basic, and it also hides many details of how type theory works, so it's
more of a hands on tutorial.

TLA+ is just a tool which basically does its job by exhaustively searching a
space of possible solutions trying to find counterexamples. It works in some
limited cases but doesn't work generally for any mathematical theorem.

~~~
pron
> TLA+ is just a tool which basically does its job by exhaustively searching a
> space of possible solutions trying to find counterexamples. It works in some
> limited cases but doesn't work generally for any mathematical theorem.

Nope. TLA+ is a rich mathematical formalism, that includes a full-fledged
proof assistant. It is, however, focused on verifying software rather than
arbitrary mathematical theorems. There is _also_ a model checker for TLA+ that
can check your theorems (about finite cases of programs) at the push of a
button. In practice, model checkers works in _more_ cases than manual proofs,
as manual proofs "fail" much more often, simply by being far too laborious; a
model checker would verify in days what may take you months or more to
manually prove.

------
MikkoFinell
A question for those of you here who are into functional programming:

Is category theory worth studying if I (coming from c++ background) am looking
to get into functional languages like Haskell? How common is it actually among
Haskell or Lisp programmers to know and utilize concepts from category theory
in their programming?

~~~
mrkgnao
A lot of the ideas used in everyday Haskell originated in category theory
(similarly to how all our programming languages eventually come from Turing
machines, the lambda calculus, and so on), but command over the mathematical
ideas is absolutely not _required_ to "get into Haskell" or even to use it
productively and fluently. It is certainly something you should look into if
you want to

a) know _why_ some things are done the way they are (in case you're not
satisfied with "this works!"), or

b) if you want to find inspiration to write a certain kind of library: Haskell
is one of the few languages that has, as I like to call it, "over 50 years of
documentation".

\--

To elaborate: a category is a bunch of _objects_ , and functions ( _morphisms_
) between the objects. The types in a language like Haskell form a category
(called _Hask_ in this case) where the objects are the types and morphisms
from one type to another are the functions that go from the former to the
latter.

A lot of things done in Haskell are instances of general constructions from
category theory applied to _Hask_. Comfort with these general constructions
certainly helps to illuminate many ideas.

For example, the great trifecta of Haskell abstractions comprises three
interfaces ("typeclasses") called Functor, Applicative, and Monad, which are
used _everywhere_. Each of these corresponds to a concept from category
theory: for instance, what a Haskeller calls a "Functor" is what is
categorically called an "endofunctor on Hask". Among users of the language who
know any category theory at all, most have some familiarity with things at the
level of what I've just said, but not much more. A knowledge of category
theory at any higher level (like in the linked repo) is not at all common,
statistically.

Also, not many of the common libraries are based on deep categorical ideas (
_lens_ [0] is an important exception) but even then, knowledge of the
mathematics is useful if you want to dig into how the ideas are implemented,
not if you're happy just using them. Learn as little or as much as you'd like.

[0]
[https://github.com/ekmett/lens/wiki/Examples](https://github.com/ekmett/lens/wiki/Examples)

~~~
MikkoFinell
Thank you, that was very illuminating.

~~~
mrkgnao
You're welcome! [http://haskellbook.com/](http://haskellbook.com/) is the
currently recommended book and is worth looking at when you start learning.

------
vfclists
And I thought he only did Emacs

