Programming Languages

Invariants are constraints on software components which restrict their behavior in some desirable way, but whose maintenance entails some kind of proof obligation discharge. Such constraints may act not only over the input and output domains, as in a purely functional setting, but also over the underlying state space, as in the case of reactive components. This talk introduces an approach for reasoning about invariants which is both compositional and calculational: compositional because it is based on rules which break the complexity of such proof obligations across the structures involved; calculational because such rules are derived thanks to an algebra of invariants encoded in the language of binary relations. A main tool of this approach is the pointfree transform of the predicate calculus, which opens the possibility of changing the underlying mathematical space so as to enable agile algebraic calculation. The development of a theory of invariant preservation requires a broad, but uniform view of computational processes embodied in software components able to take into account data persistence and continued interaction. Such is the plan for this talk: we first introduce such processes as arrows, and then invariants as their types. 1 Components as Arrows Probably the most elementary model of a computational process is that of a function f : I −→ O, which specifies a transformation rule between two structures I and O. In a (metaphorical) sense, this may be dubbed as the ‘engineer’s view’ of reality: here is a recipe to build gnus from gnats. Often, however, reality is not so simple. For example, one may know how to produce ‘gnus’ from ‘gnats’ but not in all cases. This is expressed by observing the output of f in a more refined context: O is replaced by O + 1 and f is said to be a partial function. In other situations one may recognise that there is some context information about ‘gnats’ that, for some reason, should be hidden from input. It may be the case that such information is huge to be give as a parameter to f , or shared by other functions as well. It might also be the case that building gnus would eventually modify the environment, thus influencing latter production of more ‘gnus’. For U a denotation of such context information, the signature of f becomes f : I −→ (O × U) . In both cases f can be typed as f : I −→ T O, F.H. de Carvalho Junior and L.S. Barbosa (Eds.): SBLP 2012, LNCS 7554, pp. 1–5, 2012. c © Springer-Verlag Berlin Heidelberg 2012