This channel has an extremely weird and fun aesthetic. A material scientist telling silent stories while making kitchen knives from things that shouldn’t be made into knives.
J'ai un fichier de N octets. J'alloue un tableau de N octets. Je lis N octets. Erreur dans Windows, EOF exception. Parce que les \r\n sont convertis en \n, le tableau va contenir moins de N octets. Ok, je fais attention de bien m'arrêter à la fin du fichier. Deuxième erreur, j'ai des \0 à la fin des sorties. J'étais encore en train de dire au reste du programme que le tableau faisait N octets. Pfiou.
I just verified that an S-expression parser recognizes only S-expressions.
Implementation: 250 LOC
Spec: 125 LOC
Proof: 700 LOC
Apparently parser combinators in total languages with dependent types is still a widely open research problem. Projects that need parsing just roll their own stuff, and rarely verify it...
coqdoc is packaged as part of Coq, so projects stuck on older versions don't benefit from bugfixes and new features. That's sad. I've been wanting to split it off but actually the whole thing should be redesigned from scratch so it doesn't seem worth it to break things only to break them again shortly after.
 A related discussion https://coq.discourse.group/t/would-coq-benefit-from-docstrings/849/3 and an idea floating around is to build something on top of OCaml's odoc.
Proving Algebraic Datatypes are “Algebraic” in #Coq
It was fun to write, hope you enjoy reading it. I tried to spellcheck it, but tbh I wouldn’t be surprise to find mistakes… If you notice some, feel free to tell me!
I’ve finally started to work on my next blogpost: Why algebraic datatypes are “algebraic,” explained.
Proofs are done[§], I need to actually write the explanation now x).
Haskell and Coq programmer
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!