the analysis of programming structure the standard course in theory of computation introduces students to turing machines and computability theory. this model prescribes what _can_ be computed, and what _cannot_ be computed, but the negative results have far more consequences. to take the common example, suppose an operating systems designer wants to determine whether or not a program will halt given enough memory or other resources. even a turing machine program cannot be designed to solve this problem---and turing machines have far more memory than any physical computer. the negative results of computability theory are also _robust_ (a principle enshrined as church's thesis): since many other models of computation, including λ-calculus, post systems, and -recursive functions, compute the same class of functions on the natural numbers, negative results from one description apply to all other descriptions.but the discipline of programming and the architecture of modern computers impose other constraints on what can be computed. the constraints are ubiquitous. for example, a combination of hardware and software in operating systems prevents programs from manipulating protected data structures except through the system interface. in programming languages, there are programs that "cannot be written," _e.g.,_ a sort procedure in pascal that works on arrays of any size. in databases, there is no datalog program to calculate the parity of a relation (see [1]). each of these settings involves a uniprocessor machine, but the constraints become even more pronounced in distributed systems: for instance, there is no mutual exclusion protocol for _n_ processors using fewer than _n_ atomic read/write registers [5]. all of these problems are computable in turing's sense: one can encode each of these problems as computation over the natural numbers, and one can write programs to solve the problems. so in what sense is church's thesis applicable? it is important to remember that computability theory only describes properties of the set of computable functions on the natural numbers (although there have been attempts to extend computability theory and complexity theory to higher-order functions; see, _e.g.,_ [13, 12, 20].) if one adopts computability theory as the _only_ theory of computation, one is naturally forced to encode other forms of computation as functions on the natural numbers. alan perlis' phrase "turing tarpit" highlights this potential misuse of computability theory: the encoding of computation into one framework forces many relevant distinctions to become lost.any attempt to explain other computing constraints must necessarily look for theories beyond computability theory. semantics aims to fill this niche: it is the mathematical analysis and synthesis of _programming structures._ the definition is admittedly broad and not historically based: semantics was originally a means of describing programming languages, and the definition covers areas not usually called "semantics." this essay attempts to flesh out this definition of semantics with examples, comparisons, and sources of theories. while most of the ideas will be familiar to the practicing semanticist, the perspective may be helpful to those in and out of the field. john c. mitchell jon g. riecke