When teaching formal methods, I often get asked how we can connect the specifications we write to the code we produce. One way we do this is with refinement. All examples are in TLA+.1 Imagine we’re designing a multithreaded counter. We don’t know how we’re going to implement it yet, so we start by specifying the abstract behavior.2 ---- MODULE abstract ---- EXTENDS Integers, Sequences VARIABLES pc, counter vars == <> \* Two threads Threads == 1.| Hillel Wayne
“Don’t write clever code.” Why not? “Because it’s hard to understand.” People who say this think of clever code such as Duff’s Device: Duff's Device send(to, from, count) registershort*to, *from; registercount; { registern =(count +7) /8; switch(count %8) { case0: do{ *to =*from++; case7: *to =*from++; case6: *to =*from++; case5: *to =*from++; case4: *to =*from++; case3: *to =*from++; case2: *to =*from++; case1: *to =*from++; } while(--n >0); } } This code is “clever” becaus...| Hillel Wayne
Recently my friend Lars Hupel and I had a discussion on why formal methods don’t compose well. You can read the conversation here. We focused mostly on composing formally-verified code. I want to talk a little more about the difficulties in composing specifications. This is half because it’s difficult for interesting reasons and half because it’s a common question from beginners. Beginners to formal specification expect specifications should be organized like programs: multiple independ...| Hillel Wayne
There’s not a whole lot on TLA+ technique out there: all the resources are either introductions or case studies. Good for people starting out, bad for people past that. I think we need to write more intermediate-level stuff, what Ben Kuhn calls Blub studies. Here’s an attempt at that. Most TLA+ properties are invariants, properties that must be true for every state in the behavior. If we have a simple counter:| Hillel Wayne