Mike Stay: "Ocaps is for reasoning about authority to cause potential side effects. In pure functional programming, they do that by saying "there aren't any". Functions only have access to inputs that are in their lexical scope. If they have any effects at all, it's on data that was explicitly passed in. In functional *reactive* programming, there's a lot of state that's outside the functional code, like message queues and databases. There's an implicit fold over the stream of incoming events."
Mark Miller: "Swasey, David et al is a great paper. Won best paper award at OOPSLA 2017. Here's the talk.
YOUTUBE hLjtIQWU0gk David Swasey, Deepak Garg, Derek Dreyer
"In scenarios such as web programming, where code is linked together from multiple sources, \emph{object capability patterns} (OCPs) provide an essential safeguard, enabling programmers to protect the private state of their objects from corruption by unknown and untrusted code. However, the benefits of OCPs in terms of program verification have never been properly formalized. In this paper, building on the recently developed Iris framework for concurrent separation logic, we develop OCPL, the first program logic for compositionally specifying and verifying OCPs in a language with closures, mutable state, and concurrency. The key idea of OCPL is to account for the interface between verified and untrusted code by adopting a well-known idea from the literature on security protocol verification, namely \emph{robust safety}. Programs that export only properly wrapped values to their environment can be proven robustly safe, meaning that their untrusted environment cannot violate their internal invariants. We use OCPL to give the first general, compositional, and machine-checked specs for several commonly-used OCPs—including the \emph{dynamic sealing}, \emph{membrane}, and \emph{caretaker} patterns—which we then use to verify robust safety for representative client code. All our results are fully mechanized in the Coq proof assistant. paper 