Generic Programming and Formal Methods

1. Generic Programmingand Formal Methods David R. Musser Rensselaer Polytechnic Institute

2. Minimal requirements: works with maximal family of types A Generic algorithm m Lift . . . Remove an unneeded requirement on the type Lift Less specialized: works with more than one type A 1 Lift Start here A Concrete algorithm: requires specific data type 0

3. A Concrete Algorithm float max_element(float a[], int N) { if (N == 0) throw MaxElementEmptyArrayError; int first = 0; float max = a[0]; while (++first < N) if (max < a[first]) max = a[first]; return max;}

4. A More Useful Interface int max_element(float a[], int first, int last) { if (first == last) return first; int result = first; while (++first != last) if (a[result] < a[first]) result = first; return result;}

5. A Linked-List Counterpart float_list_node* max_element(float_list_node* first, float_list_node* last) { if (first == last) return first; float_list_node* result = first; while (first->next != last) if (result->data < first->data) result = first; return result;}

6. Back to the Array Version int max_element(float a[], int first, int last) { if (first == last) return first; int result = first; while (++first != last) if (a[result] < a[first]) result = first; return result;}

7. Generalize the Element Type template <typename E>int max_element(E a[], int first, int last) { if (first == last) return first; int result = first; while (++first != last) if (a[result] < a[first]) result = first; return result;}

8. From Arrays to Pointers template <typename T>T*max_element(T* first, T* last) { if (first == last) return first; T* result = first; while (++first != last) if (*result < *first) result = first; return result;}

9. Generalize from Pointers to Iterators template <typename ForwardIterator>ForwardIterator max_element(ForwardIterator first, ForwardIterator last){ if (first == last) return first; ForwardIterator result = first; while (++first != last) if (*result < *first) result = first; return result;}

10. Use with any Container with appropriate iterators int a[] = {6, 3, 7, 5};int* ai = max_element(a, a+4);vector<int> v(a, a+4);vector<int>::iterator vi = max_element(v.begin(), v.end());list<int> x(a, a+4); list<int>::iterator li = max_element(x.begin(), x.end());. . .

11. Generic algorithm on max_element ++i Forward Container Concept *i i==j k = ++j*j = 3*k = 7 j k j k 3 7 3 7 max_element max_element

12. Container Part of the STL Container Concept Taxonomy Forward Container … Sequence Reversible Container Front InsertionSequence Back InsertionSequence Random Access Container Vector Slist Deque List

13. Input Iterator Output Iterator Forward Iterator Ostream iterator Istream iterator Bidirectional Iterator Slist iterator Random Access Iterator The STL Iterator Concept Taxonomy List iterator Deque iterator Vector iterator

14. Algorithms, Concepts, and Challenges Generic algorithms Concept Taxonomy Making Concepts First Class Constructs C requires . . . template <typename T models C>. . . assert T models C A m Lift . . Lift . . . for formal checking of syntactic and semantic properties and using them in software engineering A 1 Lift A 0 Concrete algorithms Useful Data and Algorithm Abstractions – a Generic Library

15. A Dilemma • STL and other concept-based generic libraries are based on mathematical principles, so it should be easier to apply formal methods to them than to “average software” • But they rest on a language substrate, C++, whose formal analysis is viewed by many to be intractable • Solving this completely will require much work at lower levels of implementation • I’m concentrating on developing formal deduction support for the key ideas and methodology of generic programming in a somewhat idealized setting.

16. An Observation • Understanding of how to prove something about a new generic component under development often depends heavily on thorough understanding of proofs about similar existing components • especially when studying how to make it even more general without losing correctness or efficiency • This means the goal of fully-automated proofs becomes much less important than it is for other applications of formal proof

17. What kind of proof system is most suitable? • Resolution provers fail on the readability requirement • So do tactics-based provers (although Isabelle-Isar overcomes this problem to an extent) • My own earlier work on interactive proof systems (Affirm, Affirm-2, Tecton) fell short • A relatively recent development: Denotational Proof Languages, and the Athena proof checking system • Due to Konstantine Arkoudas (MIT PhD Dissertation, 2000)

18. Athena Proof-Checker (K. Arkoudas) • Supports proofs that are both human-readable and machine checkable • Supports generalization and specialization through methods, which are deductive counterpart of (higher-order) functions • Using only its built-in and library-defined capabilities, often requires writing proofs in excessive detail • But also allows skipping over details via calls of external full-automation provers (originally Otter, currently SPASS and Vampire) • Also connects with a model checker (Paradox) so that one can easily look for counterexamples before investing effort in developing a proof

19. On the C++ Language Issue • C++ is the language in which most generic library development has been done • due to better support than most other languages: templates, template partial specialization, operator overloading, function-inlining • resulting in essentially no “abstraction penalty” at runtime • Is a formal semantics for C++ possible? • For unrestricted programming it would be very complex since there are few language-imposed restrictions on low-level features like pointers • But generic programming principles impose a simplifying discipline, enforced by well-designed concept requirements • Will require collaboration with those who can influence the future evolution of the language • a recent promising development: the C++ Standard Committee is considering proposals to add concepts as a first class feature of the language