[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Generalizing Types as Provable Invariants
A static type system can be thought of as a small framework for
proving invariants about a program -- in a type-safe language, if a
variable is typed as an integer then I know that I can't get a string
out of it. The compiler knows it too and doesn't let me modify the
program to violate that assumption.
How much work has been done on generalizing the notion of a static
type system into a more complete framework for proving interesting
invariants about a program? In essence, I'd like the source code of
a program to consist of two interweaved parts:
1. The actual code of the program
2. Machine-checkable proofs of assertions about the program
Viewed this way, parametrized types are only a slightly more
sophisticated proof system than monomorphic types. I'd like to be
able to write a simple proof that, say, the index of an array access
will never exceed the dynamic size of the array I'm using. In
another case I'd like to write a proof that the insert routine will
leave my tree sorted if it was sorted before. I'd also like to be
able to define new kinds of characteristics (rather than just
membership in a set or range) that can be manipulated by the
machine-checkable proofs. Furthermore, these assertions should be
easy to communicate and machine-verify across abstraction boundaries
in the language.
Something like this might be useful in the maintenance of large
systems. I find that the hardest part nowadays in developing large
systems isn't writing the initial code; rather, it is keeping track
of the assumptions that were made along the way and ensuring (hoping
in most cases) that modifications respect those assumptions.
Furthermore, as a system evolves, invariably the invariants
themselves have to evolve; it would be nice to be able to change what
the invariant is and have the compiler notify me of all cases/uses I
forgot to consider. Having assertions in a language or development
methodology helps a little, but doesn't provide much design insight
and only works if the test cases happen to exercise the code well.
Waldemar