Chapter 7 Logic of behavior: Sheaves, toposes, and internal languages In this chapter, we will study the notion of behavior and interaction by defining a category BT whose objects we call behavior types. Doing so will refine exactly what we mean by behavior, as well as how different types of behavior relate. However, our formulation will do much more: it will give us a formal language and logic in which to prove properties of behaviors in systems. 7.1 Motivation: a logic for composing machines Imagine you are trying to design a system of interacting components. You wouldn’t be doing this if you didn’t have a goal in mind: you want the system to do something, to behave in a certain way (even gods know what they think is “good” for the system they design.) Luckily, in the given case the possible behavior of any system in any environment is determined by the possible behaviors of each of its components, together with the precise way in which they interact.1 In this chapter, we will discuss a logic wherein one can describe general types of behavior that occur over time, and prove properties of a larger-scale system from the properties and interaction patterns of its components. 7.1.1 Systems and components For example, suppose we want an autonomous vehicle to maintain a distance of at least s safe from another object. To do so, several components must interact: a ≥ 1 The well-known concept of emergence is not about possibilities, it is about prediction. Predicting the behavior of a system given predictions of its components is notoriously hard. The behavior of a double pendulum is chaotic—meaning extremely sensitive to initial conditions—whereas those of the two component pendulums are not. However, the set of possibilities for the double pendulum are completely understood: it is the set of possible angular positions and velocities of both arms. When we speak of a machine’s properties in this chapter, we always mean the guarantees on its behaviors, not the probabilities involved. 1 CHAPTER 7. LOGIC OF BEHAVIOR: SHEAVES, TOPOSES, AND INTERNAL 2 LANGUAGES sensor that approximates the real distance by an internal variable s , say s s, a 0 0 ≈ controller that uses s0 to decide what action a to take, and a motor that moves the vehicle with an acceleration based on a. This in turn affects the real distance s, so there is a feedback loop. Consider the following model diagram: s sensor controller motor s0 a s In the diagram shown, the distance s is exposed by the exterior interface. This just means we imagine s as being a variable that other components of a larger system may want to interact with. We could have exposed no variables (making it a closed system) or we could have exposed a and/or s0. In order for the system to ensure s safe, we need each of the components to ≥ ensure a property of its own. But what are these components, “sensor, controller, motor”, and what do they do? One way to think about any of the components is to open it up and see how it is put together; with a detailed study we may be able to say what it will do. For example, just as s was exposed in the diagram above, one could imagine opening up the sensor component and seeing an interaction between subcomponents sensor radar s processor s0 sonar This ability to zoom in and see a single unit as being composed of others is important for design. But at the end of the day, you eventually need to stop diving down and simply use the properties of the components in front of you to prove properties of the composed system. Your job is to design the system at a given level, taking the component properties of lower-level systems as given. We will think of each component in terms of the relationship it maintains (through time) between the ports on its interface. We will make this more precise soon, but examples should help. The sensor maintains a relationship between s and s0, e.g. that they differ by no more than 5cm. The controller maintains a relationship between s0 and the action signal a, e.g. that if at any time s < safe, then within one second it will emit the signal a go. The motor maintains a relationship between a and s, e.g. that a dictates the second derivative of s by the formula a go s > 1 a stop s 0 : (7.1) ¹ ) Ü º ^ ¹ ) Ü º 7.1. MOTIVATION: A LOGIC FOR COMPOSING MACHINES 3 The above formula, and the rest, need to have unambiguous interpretations in a formal logical language, in which we can use standard proof techniques to combine properties of subsystems into properties of the whole. This is our objective in the present chapter. 7.1.2 A language for behavioral properties We have said how component systems, wired together in some arrangement, create larger-scale systems. We have also said that, given the wiring arrangement, the behav- ioral properties of the component system behaviors dictate the behavioral properties of the whole. But what exactly are behavioral properties? In this chapter, we want to give a formal language and semantics for a very general notion of behavior. Mathematics is itself gives a formal language; the usual style of mathematical modeling is to use any piece of this vast language at any time and for any reason. One uses “human understanding” to ensure that the different linguistic pieces are fitting together in an appropriate way when different systems are combined. Where the present work differs is that we want to find a domain-specific language for modeling behavior, any sort of behavior, and nothing but behavior. Unlike in the wide world of math, we want a setting where the only things that can be discussed are behaviors. For this, we will construct what is called a topos, which is a special kind of category. Our topos, let’s call it BT, will have behavior types as its objects. An amazing fact about toposes is that they come with an internal language that looks very much like the usual formal language of mathematics itself. Thus one can define groups, topological spaces, etc. in any topos. But in BT, groups will be group-like behavior types, e.g. where the group changes through time; topological spaces will be topological space- like behavior types, e.g. where the space changes through time. Rather than living in the world of sets—where elements are constant through time—we will live in the world of behavior types, which can change through time. The topos BT not only has an internal language, but it has a mathematical semantics using the notion of sheaves. A sheaf is a certain sort of functor. Every property we prove about behavior types will have meaning in this category of sheaves. When discussing systems and components above in Section 7.1.1, we mentioned behavior types; these will be the objects in the topos BT. Every wire in the picture below will stand for a behavior type, and every box will stand for a behavior contract, relating the wires it touches. s sensor controller motor s0 a s For example CHAPTER 7. LOGIC OF BEHAVIOR: SHEAVES, TOPOSES, AND INTERNAL 4 LANGUAGES • There is a behavior type for distances s between our vehicle and the other object; perhaps its behaviors are real-valued continuous functions of time. • There is a behavior type for action-signals a emanating from the controller; perhaps its behaviors are piecewise-constant functions of time taking values in a finite set such as go; stop . f g • The controller itself is a behavior contract on pair s ; a , while the motor is a ¹ 0 º behavior contract on a pair a; s e.g. the one shown in Eq. (7.1). ¹ º 7.2 Introduction to toposes, sheaves, and their logic In this section, we introduce toposes and sheaves. We give a brief history and some first definitions in Section 7.2.1. Then we discuss topological spaces and sheaves on them in Section 7.2.2. This leads into the definition and basic properties of toposes, which we discuss in Section 7.2.3. In particular, we explain how toposes are related to logic in Section 7.2.4 and quickly discuss type theories and semantics in Section 7.2.5. We will not discuss a specific topos of behavior types until Section 7.3. 7.2.1 Toposes A topos is defined to be a category of sheaves.2 So for any space X; Op , the category ¹ º Shv X; Op defined in Definition 7.10 is a topos. Also, for any database schema—i.e. ¹ º finitely presented category— , the category -Inst of database instances on is a C C C topos. Toposes encompass both of these sources of examples, and much more. The point is, a topos is a category that happens to be the category of sheaves E on something. There are several things that make toposes really nice; one is that every topos has much of the same structural properties that the category Set has. For example, here are some structures and properties enjoyed by every topos : E 1. has all limits, E 2. has all colimits, E 3. is cartesian closed, E 4. has epi-mono factorizations, E true 5. has a subobject classifier 1 Ω E −−−! We need to explain a few of these.