On Fri, May 24, 2024 at 8:18 PM Bakul Shah via TUHS <tuhs(a)tuhs.org> wrote:
At one point I had suggested turning Go's Interface type to something like
Guttag style abstract data types in that relevant
axioms are specified
right in the interface definition. The idea was that any concrete type that
implements that interface must satisfy its axioms. Even if the compiler
ignored these axioms, one can write a support program that can generate a
set of comprehensive tests based on these axioms. [Right now a type
"implementing" an interface only needs to have a set of methods that
exactly match the interface methods but nothing more] The underlying idea
is that each type is in essence a constraint on what values an instance of
that type can take. So adding such axioms simply tightens (& documents)
these constraints. Just the process of coming up with such axioms can
improve the design (sor of like test driven design but better!).
At one point I worked with a programming language called Gypsy that
implemented this concept. Each routine had a prefix that specified axioms
on the routine's parameters and outputs. The rest of Gypsy was a
conventional procedural language but the semantics were carefully chosen to
allow for automated proof of correctness. I wrote a formal specification
for the DECnet session layer protocol (DECnet's equivalent of TCP) in
Gypsy. I turned up a subtle bug in the prose version of the protocol
specification in the process.
-Paul W.