Raymond Turner. July 10, 2009. Abstract. We examine the difference between theory construction in science and specification in engineering. We then use this ...
SPECIFICATION and THEORY CONSTRUCTION in COMPUTER SCIENCE Raymond Turner July 10, 2009 Abstract We examine the di¤erence between theory construction in science and speci…cation in engineering. We then use this to explore some aspects of computer science. Some of the discussion will be in‡uenced by the rule following considerations.
1
Speci…cation versus Theory Construction
Given a naturally occurring artefact, a scientist attempts to understand it. To do so, she makes some initial observations, prods and pokes it, literally and …guratively, and formulates some hypothesis about its function: what is it and what does it do? Eventually, she may formulate a theory about it. Such theories provide an explanation of the initial observations, and are often mathematically expressed. Consequently, they sanction the drawing of predictions that are formal consequences of the theory. And these provide the mechanism whereby the theory may be tested empirically. If the predictions turn out to be false, the theory may have to be revised. Subsequently, theory construction cycles through alternate stages of theory articulation and empirical veri…cation. In contrast, engineers deal with constructed artefacts that are designed and built to meet some functional speci…cation. The latter is formulated very early on in the whole process. And its expression can range from a graphical representation through to something more mathematical in ‡avor and content, and is often accompanied by some natural language commentary. They are not intended to be explanatory but normative. Once in place, the engineer turns to the construction of the physical device itself. This may involve a further set of design phases until the actual thing is produced. These artefacts are not discovered but are built to meet their speci…cations. Like scienti…c theories, they may have mathematical consequences, and these can act as predictions about the properties of the constructed device, and become the focus of its testing. Of course, the physical device may not measure up to its abstract speci…cation. In such cases, we say that the device has malfunctioned, and does not re‡ect the designer’s intentions. If it fails, the device needs to be rebuilt.
1
Undoubtedly, these characterizations oversimplify both engineering and science, and indeed, their relationship. For one thing, scientists do not change their theories as easily as this simplistic characterization suggests. So-called normal science, where a theory dominates, can last some considerable time. The move from Newtonian to Einsteinian physics is often cited as an example. Indeed, changes of theory, especially the big paradigm shifts [20], happen quite infrequently, and during the periods of normal science, theories play a more normative role. However, the kind of theory that we here envisage is not this grand. They have very local interest and signi…cance, and are subject to rapid change and revision. In a parallel way, the engineer does not hold onto the speci…cation no matter what. Its normative status may be given up in the light of continual practical failures to build a device that satis…es it. It may just turn out to be physically infeasible. However, this is the last, not the …rst, resort. Even within the two endeavours there are possible di¤erences which we have glossed over. Di¤erent branches of engineering may di¤er in terms of their methodology, the role of mathematics and their design tools. For example, are the methodologies of mechanical and electrical engineering the same? Do mechanical engineers specify and design in the same way as the electronic ones? Likewise, we may ask whether theory formulation and veri…cation is the same in Biology, Astronomy and Psychology. To what extent does the very di¤erent subject matter of these areas a¤ect the nature and style of theory formulation? On the bigger picture, engineering and science have much in common. And this is slightly obscured by our characterizations. Firstly, both have the potential to exploit mathematical models: the engineer in the speci…cation of the artefact and the scientist in the formulation of the theory. This is an applied use of mathematics in the sense that these models are not being constructed for contemplation purposes; they are tools in the scienti…c and engineering processes. Furthermore, both enterprises contain elements of both scenarios. Engineers employ and formulate theories to aid the design process. For example, theories about the nature of materials is partly the work of engineers. Likewise, scientists design machinery and tools for experimental purposes. Speci…cally, Faraday’s famous experiments on electromagnetism, involved the design of the quite complex physical apparatus necessary to demonstrate the phenomenon. Again contrary to the impression given by our characterization, the major di¤erence between the two is not primarily located in the nature of the artefacts themselves. Even naturally occurring artefacts can be treated from the engineering perspective (reverse engineered). We may, for example, wish to reproduce a dog’s nose. In which case, we will use the relevant scienti…c knowledge to specify and design the arti…cial one. Our speci…cation will have to abstract away from the physical nose, and maybe compromise on its sni¢ ng power. A dog’s nose has something like twenty times as many primary receptor cells as the human nose, and di¤erent regions of the mucous lining within the nose have di¤erent chemical properties. Unfortunately, for our engineering task, canine noses are still a bit of a mystery. And so we may have to settle for a child’s nose: its power may be restricted to it ability to sense breast milk. On the other hand, in order to discover what they do, constructed artefacts may be explored 2
scienti…cally. We might …nd a strange machine in the garden and subject it to scienti…c investigation, and even formulate a theory about its function: it is a device for smelling ‡owers, an arti…cial nose. So our characterization hides a multitude of similarities and overlaps. Nevertheless, despite these more delicate observations, our crude caricatures highlight a signi…cant di¤erence of attitude between science and engineering: they bring to the fore the di¤erences between the way in which engineers proceed when they are designing artefacts and the way scientists do when they are investigating them. In their primary role, engineers specify and design, while scientists formulate theories. Both test, but to di¤erent ends. In particular, when tests establish that things have gone astray, the scientist blames her theory, but the engineer blames the artefact and its construction. Later, more radical revisions may occur. But for the engineer the speci…cation is primary whereas for the scientist the empirical data dictates; in reaction to problems, one gives up the abstract theory and the other gives up the physical object. Again these oversimplify actual practice, but not much hangs on whether these cleanly characterize the two endeavours. They point to an important di¤erence between the activity of theory construction and that of speci…cation and design. And this concerns the normative nature of speci…cations versus the defeasible nature of scienti…c theories. And it is this that will help us to unravel some of the issues concerning the nature of computer science.
2
The Varieties of Computer Science
Writers have o¤ered many di¤erent characterizations of computer science (e.g. [39], [10], [9], [7], [17], [18], [18]). Many of these have concluded that it is a scienti…c discipline and others that it is essentially engineering. In contrast, in almost all universities in USA and the UK, computer science is contained in engineering faculties1 . And many practitioners think of themselves as engineers. Of course, no one believes that computer science does not contain elements of both disciplines, as well as a good deal of mathematical activity. But there is little clarity here. What complicates the issue is the wide range of activities covered under the umbrella of computer science. At one end of the spectrum there are very mathematical ones that are concerned with the mathematical investigation of type systems ([2], [25]), semantic theories of programming languages and programs ([22], [12], [32], [33]), the analysis of algorithms and their complexity ([4], [14]), and much more. Indeed, computer science uses a vast range of mathematical structures from topology, set theory, mathematical logic, model theory, algebra, category theory, analysis, probability theory etc. Almost every branch of contemporary mathematics has found some application. Furthermore, computer science has invented new areas of mathematics and, in particular, a whole range of new logics [13] including substructural ([15], [27]) and modal logics [16]. Much of this activity, that goes 1 Others have held that it is an essentially mathematical activity [18]. We shall discuss this later.
3
under the banner of theoretical computer science, is mathematical, and often more closely resembles pure rather than applied mathematics. A middle section involves the design of programming, speci…cation and architectural description languages, compilers, interpreters, operating systems etc. and their application to the design, implementation of computational systems ([5], [38]). Here mathematics is used, mostly in its applied form, to specify and investigate them. The ‡ip side of this is concerned with the design and construction of the actual physical apparatus on which these software systems operate. Activities include the design of computers and embedded systems [24]. The material of this middle section is often taken by many to be the core of the subject, and prima facie, it …ts our engineering caricature. At the other end, the subject sucks in and relates to many other areas that have their own goals and methodology. Computational biology [6], computational economics and …nance [29], and all the areas of arti…cial intelligence and cognitive science [28], are obvious examples. On the face of it, much of this activity is scienti…c in nature: it involves theory formulation and veri…cation. Given all this, it seems clear that the subject includes subareas that center upon all three disciplines: mathematics (pure and applied), science and engineering. The idea that this wide range of activities can be neatly packaged as one thing, is obviously too simplistic, and plainly just wrong. It is not even that clear why it is philosophically interesting to place it in these pigeon holes that are largely socially and politically determined. Moreover, a complete investigation of its nature would be a substantial project. But we shall not be that ambitious: we shall make a few forays into the subject i.e., we shall use our notions of speci…cation and theory construction to explore some topics in computer science, and see what insights we can glean. This will throw up some subtle issues, and take us to some central parts of the subject, and to the conceptual questions that surround them. Much of our discussion will be concerned with the impact of the rule-following considerations ([40], [3], [21]) on the nature of machines, programs and programming languages.
3
Machines: Abstract and Physical
Machines, abstract and physical, form a central place in computer science. The study of abstract automata and the design, use and construction of actual computers are core aspects of the discipline. Moreover, the abstract machines maybe taken to be mathematical models of the physical ones. This relationship will provide the …rst focus for our investigation. To begin with, we introduce a simple abstract machine whose underlying state consists of named locations with numerical content. Here x; y; z:::name locations and 3; 4; 7:::are its present numerical contents. h i 3 4 7 : : : x
y
z
The role of the state is to store numerical values in locations. So that 3 is stored at location x; 4 at location y etc. The machine has an operation Content that 4
given a state, returns the content of a location, and a second one, U pdate that given a state changes the value in a given location. For example, when given the location named y and the value 6, the resulting state is given as: h i 3 6 7 : : : x
y
z
And the contents of this state at location y is now 6. Actually, we can abandon these pictures and approach matters more abstractly in terms of the following axiomatic demands: for any number n and any locations l, k and any state s Content(k; U pdate(l; n; s)) Content(k; U pdate(l; n; s))
= n = Content(k; s)
k=l k 6= l
1 2
This describes a simple machine with a notion of state and a two operations that act upon it. This is a mathematical device that is determined by these axioms that govern the Contents and U pdate operations. The notion of state is now left implicit. On the basis of these axioms, it may be mathematically explored. For example, we can easily prove from them that, for any state s and any locations l; k; Content(k; U pdate(l; n; U pdate(l; n; s))) = Content(k; U pdate(l; n; s)) That is, doing two identical updates is a waste of time. The operation Update can be expressed as an operation that, given a location and a number, returns an operation that alters the state. We may indicate this as U pdate : L ) (N ) (State ) State)) where we take L and N to be types and L ) K describes the type of operations that map objects of type L into those of type K 2 . Similarly, the Contents operation, given location and a state, returns a number, and so has the following type. Contents : L ) (State ) N ) We have characterized matters axiomatically. But it is easy enough to give a set-theoretic interpretation. Here we take L to be the set of locations and N to be the set of natural numbers, and we model states as …nite sets of ordered pairs i.e., State = Sets (L N ) where forms Cartesian products. The operations Contents and U pdate are now interpreted as set theoretic functions. Moreover, in this set theoretic model states are extensional i.e., they are determined by their elements. However, the 2 We are using the notion of type in its theoretical computer science sense. As such there would be axioms or rules governing membership. In a more complete description, we would more carefully spell-out the nature of these types. For example, we would expect that 0 is a number and every number has a successor etc. The same applies to the type of operations ([13], [25], [35], [36], [37]).
5
choice of sets as the mathematical framework is purely for illustrative purposes. There are many other options including our original pictures taken to be two dimensional arrays with some standard axiomatization of their properties. But the choice is not germane to the present issue. Most of what we shall say will not be a¤ected by the particular choice of mathematical underpinnings3 . We only need them to be mathematical devices. From the engineering perspective this abstract machine may be taken to be a speci…cation of a proposed physical device; one that is to be constructed. This has to have a physical store with physical locations and contents, and a physical means of performing the Content and U pdate operations. In addition, the physical machine itself has to be designed. There will be requirements not speci…ed in the abstract speci…cation, such as what materials to use, whether it be a mechanical device or a digital one with silicon components etc. All of these considerations would need to be made explicit in any realistic design. But, what makes it a physical device is not what it is made of, but that it subject to the laws of physics. Clearly, physical and abstract devices have very di¤erent properties and very di¤erent roles in computer science: one is governed by mathematical manipulations and inferences, and the other is subject to the laws of physics. Consequently, talk of the program running on the abstract machine needs to be understood as a mathematical notion. It maybe that it is introduced by analogy with the physical one, but literally, nothing runs on the abstract machine; it is a non-spatial, atemporal mathematical object. On the other hand, the physical machine may not measure up to its abstract idealization which presumably re‡ects the machine designers intentions. Physical machines wear out, overheat, their fans get clogged with dust etc. As a consequence, the physical update operation, when given y and 6; may generate the state 3 9 7 : x
y
z
: :
So something has gone wrong; we wish to say that the machine has malfunctioned. But taken by itself, we cannot say this. For without some independent speci…cation, we have nothing to measure the physical machine against. By itself, it just does what it does. This is not a new observation. Its roots can be traced to Wittgenstein’s rule following considerations. Indeed, the fact that a physical machine cannot act as its own speci…cation has been explicitly made by Kripke’s Wittgenstein. Here, the function that the machine is intended to compute is its speci…cation. I cannot really insist that the values of the of the function are given by the machine. First, the machine is a …nite object, accepting only …nitely many numbers as input and yielding only …nite many as output - others are simply too big. Inde…nitely, many programs extend the actual …nite behavior of the machine. Usually this is ignored 3 There are signi…cant issues here that have little to contribute to the main point of the present paper. We shall address them on another occasion.
6
because the designer of the machine intended it to ful…ll just one program, but in the present context such an approach to the intentions of the designer simply gives the sceptic his wedge to interpret in a nonstandard way. (Indeed, the appeal to the designer’s program makes the physical machine super‡uous; only the program is really relevant. The machine as physical object is of value only if the intended function can somehow be read o¤ from the physical object alone.) Second, in practice it is hardly likely that I really intend to entrust the values of a function to the operation of a physical machine, even for that …nite section of the function for which the machine can operate. Actual machines can malfunction: through melting wires or slipping gears they may give the wrong answer. How is it determined when a malfunction occurs? By reference to the program of the machine, as intended by its designer, not simply by reference to the machine itself. Depending on the intent of the designer, any particular phenomenon may or may not count as a machine malfunction. A programmer with suitable intentions might even have intended to make use the fact that wires melt or gears slip, so that a machine that is malfunctioning for me is behaving perfectly for him. Whether a machine ever malfunctions and, if so, when, is not a property of the machine itself as a physical object but is well de…ned only in terms of its program, stipulated by its designer. Given the program, once again, the physical object is super‡uous for the purpose of determining what function is meant, [21] page 34. The notion of malfunction must be measured against the abstract one that re‡ects the designers intentions. And this cannot be the physical machine itself, or any other physical machine, since the later itself will need its designers intentions articulated. We can stop this regress only by reference to an abstract one4 . Abstract machines play the normative function: the physical ones are measured against them, where the physical machine meets its abstract speci…cation if its actual input/output behavior is in agreement with the abstract machines axioms. Of course, this is an empirical matter; we need to run it and see. We cannot prove mathematically that it does. Moreover, we will never be able to completely verify their agreement: the best we can do is to carry out tests until we are convinced - or the machine malfunctions. If the latter, our machine build is wrong. This is the specify and design strategy, the standard engineering picture: abstract designs are speci…ed and physical devices are constructed to meet their demands. When the physical machine malfunctions, we go back to the drawing board for the design of the physical machine; but, at this stage, we do not change the abstract one. The alternative picture is the route of theory construction, and here matters are perceived quite di¤erently. Here the physical device is the thing that is given 4 Of course, the rule following considerations penetrate here also. But exactly how, is much more contentious. And here is not the place to enter this debate. The fact that a physical machine cannot act as its own speci…cation, is not controversial. And this is all we need.
7
to us, in the guise of a natural artefact. The computer science task is to …gure out how it works. What do the handles marked U pdate and Contents do? On this perspective, these operations are determined by what the physical machine actually does. When we experiment and discover that the contents button of the physical device outputs a number, we postulate the idea that it is a simple state machine that holds numbers etc. On this picture, we attempt to construct some kind of theory about the machine i.e., we postulate an abstract machine as a theory of the physical one. We might even formulate axioms 1; 2 as the theory of the device. We may then subject it to some form of empirical veri…cation. For instance, if, when given y and 6; the physical machine generates the state 3 9 7 : x
y
z
:
: ;
this to be taken to be what update operation does. And our model determined by our two axioms is falsi…ed. So we don’t go back to the drawing board; we go back to theory construction. Perhaps something of this sort is involved when cognitive scientists attempt to build functional models of human intelligence or when Sun engineers seek to diagnose a malfunctioning machine. But this does not seem to be a plausible picture of how we view computers. Surely, in its primary role, the physical machine, a computer, is not a natural device that we are trying to build a theory of. It is a designed artefact that has been designed to behave in a certain way. Our axioms are not a theory of a naturally occurring artefact, but design criteria that lay down the norm for the design and construction of the physical machine. This is engineering design. On the other hand, the scienti…c picture seems to have some purchase because of the complexity of computers: they are so complex and unpredictable that, no matter how carefully they are built to meet their speci…cations, they are bound to malfunction. Consequently, their speci…cations are no longer a reliable guide. Presumably, we need to analyze what is actually going on; we need to build a theory of the device as it is actually functioning. All this seems plausible, but to overemphasize this troubleshooting role, and make it as methodological signi…cant as the design methodology, is to ignore the normative function of speci…cation. The full implications of this will more clearly drawn in the context of programming language semantics.
4
Abstract Machine Semantics
The syntax of a programming language is given via a formal grammar of some sort. For example, the following provides part of the syntax for a simple imperative language in a standard recursive notation, where P stands for programs and B for Boolean expressions. P = x := n j P ; P j if B then P else P j Scrap This grammar pins down what the legal strings of the language are. But that is all. It does not completely determine the thing that people program in; it 8
tells us nothing about the intended meanings. It provides no account of what happens when they are executed. While we may guess that these are imperative statements, and even guess that the …rst instruction assigns a value (given by numeral n) to a variable (x), in order to use the language as a programmer or to write a compiler for it, we need a semantic account. In particular, I suspect the reader will have no idea what Scrap does. But how is this semantics to be given? This is where our abstract machine enters the picture: the language and programs written in it maybe semantically …xed by an abstract machine (e.g. [22], [12], [32], [33]). We shall brie‡y indicate how this is achieved with our simple language. We specify the semantics by an operation that associates, with each program, a state transformation. Thus the type of the semantic operation is given as follows, where P rogram is the type of programs. C : P rogram ) (State ) State) This is given compositionally by the following semantic clauses that unpack the meaning of the language. We write C kP k s for the result of applying the operation to the program P in state s. The simple assignment statement is built into our abstract machine as a basic operation. C kx := nk s = U pdate(x; n; s)
3
The second construct, sequencing, is modelled by composition i.e., perform the …rst, get the resulting state, and then apply the second. C kP1 ; P2 k s = C kP2 k (C kP1 k s)
4
The conditional has it standard meaning: the result depends upon the value of the Boolean, which is either true or false. C kif B then P1 else P2 k s =
C kP1 k s if B = true C kP2 k s if B = f alse
5
Finally, Scrap is taken to denote the identity operation i.e., it returns the same state as it is given. C kScrapk s = s 6 This is not intended to be useful, but merely to demonstrate that the semantics is normative. And although it might be considered odd or non standard, a language designer is also at liberty to de…ne the conditional as follows. C kif B then P1 else P2 k s =
C kP1 k s if B = f alse C kP2 k s if B = true
(6 )
This is now what it is taken to mean. You get what you specify and nothing else. 9
But whichever choice is made, such axioms provide a mathematical account5 that supports reasoning about the language and its programs. For example, given 3; 4; 5; 6 we may prove the following. C kif true then (if f alse then Scrap else P ) else Scrapk s = C kP k s Although a very simple case study, this already demonstrates the normative nature of abstract machines semantics. It also gives us some insight into the semantic status of programs. On this view, the substance of programs, their real semantic content, is an abstract object, an operation, that is determined by the semantic interpretation into its underlying abstract machine6 . We shall refer to this as the abstract program. Consequently, questions of program equality relate to these abstract programs. So that two symbolic programs are taken to be equal, if they denote the same abstract program. For example, on our semantic account, the following equality is supported if true then (if f alse then Scrap else P ) else Scrap = P Of course, there may be many such semantic accounts and each determines an equality notion. The ones given here are quite extensional and identify programs with operations on states. More intensional ones that take computations into account, lead to various forms of operational semantics [12]. But without further argument, none will settle the practical issues raised by legal discussion over when two symbolic programs are to be taken to be the same. However, the semantic perspective does shift the practical question to the abstract machine level/programming language level. It provides the appropriate conceptual setting within which we might address such questions. The core ontological point is that the identity of programs is semantically determined by the abstract machine, and the induced interpretation of their host programming language. The abstract machine account is in line with the engineering paradigm. The semantic clauses provide the speci…cation of the language. Any implementation on an actual machine i.e., one that ends in physical operations on the machine, will be subject to testing against the speci…cation. And in the end this will involve much the same process as the testing of the basic machines operations of the physical machine against the axioms of the abstract one7 . 5 Again we could interpret all this set theoretically. In its original formulation sets were used where the underlying sets were complete lattices. There is also an issue over the nature of equality here, namely should equality be a version of partial or total equality. In domain theory, because of the existence of a bottom in the lattice, equality was taken to be total. But neither of these issues impinges on the central point of this section. 6 Are the abstract programs designed mathematical objects? By this we mean are they abstract objects that have been designed? This is of course part of a much more well known mathematical problem over the nature of mathematical objects [30]. The Platonist would say no, they are discovered not designed. Whereas, the antirealist position that they are invented by mathematicians, is closer is to present view of programs. 7 Along the way we shall have to deal with the compiler from the language to the machine code, and deal with its correctness. But we shall discuss this issue on another occasion.
10
5
Programming Languages as Scienti…c Theories
Despite all this, when asked how the semantics of a programming language should be given, many practitioners would reject such abstract accounts in favour of one views a programing language as a scienti…c theory8 . The average programmer in the street would insist that it is what actually happens on the actual physical device on which the language is implemented, that provides the meaning of the constructs. The reasoning here is of a practical nature: to actually use a programming language, we need to know what actually happens when programs are run. An abstract semantics might satisfy the mathematician, but has little to do with what the practical programmer, who has to make the programs run on a given physical machine, knows. Leaving aside the problem of how exactly each of these constructs might be given a physical interpretation9 , the claim is that the meaning of a program construct is determined by what the physical machine does. On this view, there is no notion of malfunction. There is no alternative court of appeal; the intentions of the programming language designer are not de…nitive. The physical machine determines the programming language, and the meaning of its constructs. It follows that, if during the running of a program the machine switches on and o¤, this to be taken as part of the programs meaning. Whatever the physical machine does, yields the meaning of the program. And allegedly, this is what the practical programmer wants; she wants to know what will actually happen. Despite all our best speci…cation intentions, modern software is not like the elementary programs written in school classes. Nor is it not as simple minded as the theoreticians toy examples that are subject to mathematical analysis. Contemporary software is so complex that, even if it is built to speci…cation, the consequences of running it on a physical machine are unpredictable. So the best we can then do is to treat it as a natural artefact, and troubleshoot it. The internet is often quoted as an instance of this phenomenon. Indeed, this is not even a designed artefact; it just evolved and is continually evolving10 . There is little doubt that a programmer does want and, up to a point, need to know what the machine actually does. But how is this to be found out and articulated? Presumably, we shall need to undertake some kind of investigation of the bundle which is the physical machine with the programs running on it; the black box that houses the behavior when the program runs. For example, if I want to use the conditional, I need to know what it does. Unless I know this, I cannot get o¤ the ground. But on this picture, how do I …gure this out i.e., how do I …gure out what the programming constructs do? Presumably, we run each one of constructs of the language and observe what happens. For example, we 8 ([8],
[7], [11]) suggest that program language statements admit of both interpretations. the present argument, we may assume that this has been done. For concreteness, we may assume that there is be a compiler into the operations of a physical machine. And the latter may well go through an enriched abstract machine with its enriched machine code. None of the details are pertinent to the present issue. 1 0 A rather di¤erent view of matters can be found in ([7], [8]). 9 For
11
run Scrap and observe that nothing happens. How exactly we observe this, or how we are to observe the behavior of complex expressions such as sequencing, should not detain us. How one is to tear apart the impact of the individual program constructs from the behavior of the supporting physical system, we may left unsaid. However unrealistic this might be in practice, for the purposes of this discussion, we may assume that we have developed some methodology to do so. We might then try and abstract some principles such as 3; 4; 5; 6. If successful, we would then have constructed a theory of the language. But, even assuming all this theory construction is feasible, does it furnish a satisfactory notion of semantics? There are a couple of obvious possible objections. Firstly, if the semantics of programs is to be taken to be a theory about their behavior on a given physical machine, it would seem to follow that anything said about programs, that involves their intended meaning, is also to be so interpreted. In particular, the correctness and equality of programs is to be determined by the physical objects running on the physical machine; it is an equality of physical mechanisms. Unfortunately, such empirical notions of correctness and equality will not satisfy the logicians. Equality is taken by them to be a logical notion. Furthermore, is a lawyer, who asks whether two programs are legally identical, asking about the behavior of programs on a particular physical machine? Or is she is concerned with something more abstract: something not to be identi…ed with either the syntactic program or any speci…c physical mechanisms? An even more devastating criticism, attacks the very motivation for this approach to semantics: in the future, the whole system may malfunction in new ways not predicted by the theory. In which case, the user requirement that initiated the scienti…c perspective (i.e., the user needs to know exactly what happens) will lead to the development of a new theory. And this almost certainly will lead to a further modi…cations. Indeed, it would seem that this user requirement is unobtainable: continual revision is required to feed this desire for exact knowledge.
6
Theory or Speci…cation?
But surely all scienti…c theories are subject to revision. Indeed, for scienti…c theories this is taken to be a strength not a weakness. Unfortunately, it is precisely this that makes them unsuitable de…nitional devices: arguments from the rule following considerations suggest that such empirical theories cannot play a semantic role. Suppose the expression ’green’ means green. It follows immediately that the expression ’green’applies correctly only to these things (the green ones) and not to those (the non-greens). The fact that the expression means something implies, that there is a whole set of normative truths about my behavior with that expression: namely, that my use of it is correct in application to certain objects and not
12
in application to others. .... The normativity of meaning turns out to be, in other words, simply a new name for the familiar fact that, regardless of whether one thinks of meaning in truth-theoretic or assertion-theoretic terms, meaningful expressions possess conditions of correct use. (On the one construal, correctness consists in true use, on the other, in warranted use.) Kripke’s insight was to realize that this observation may be converted into a condition of adequacy on theories of the determination of meaning: any proposed candidate for the property in virtue of which an expression has meaning, must be such as to ground the ’normativity’of meaning-it ought to be possible to read o¤ from any alleged meaning constituting property of a word, what is the correct use of that word. [3] A programming language must be grounded in order to play its normative role i.e., meaningful programs have conditions of correct use, and a semantics must lay down these conditions; and thus enable the user to distinguish between its correct and incorrect use. So while the very same set of axioms (3; 4; 5; 6) may be interpreted as either a scienti…c theory about the language or as a speci…cation of it, it is only the latter that can qualify as a semantic account. This is not to say that the physical system as an artefact need not be tested. Of course it must. But in the engineering sense: we are testing to see whether the supporting devices meets their speci…cations. For example, we might test to see whether the physical machine does. But it is not the speci…cation of the programming language (or any other speci…cation for that matter) that is under scrutiny. The semantic speci…cations are not the things under test11 . If we take 3; 4; 5; 6 as a semantics of the language, and we observe the behavior of the conditional to be in-line with 6 , rather than 6, we need to say that the physical system has malfunctioned, not that the semantics is wrong. This appears not to leave any role for (3; 4; 5; 6) as a scienti…c theory of the language. If this is right, machine and language design/speci…cation seem to be best described by the engineering paradigm. I suspect much the same is true about programming and software development, but this needs more re‡ection.
References [1] Allison, L. A Practical Introduction to Denotational Semantics. Cambridge Computer Science Texts. Cambridge. 1990. [2] Barendregt, H.P. "Lambda calculi with types". in: Handbook of logic in computer science, Vol. 3. New York, NY: Oxford University Press Inc. 1993. [3] Boghossian, P.A. "The rule-following considerations". Mind 89. 1989. 1 1 We do not deny that abstract as well as physical objects may be subjected to speci…cation and testing. But some care is needed in saying exactly what is involved when one experiments with such. In any case, this is a subject for another occasion.
13
[4] Bovet, D. P., Crescenzi, P. Introduction of the Theory of Complexity. Prentice-Hall. London. 1980 [5] Brookshear, J.G. Computer Science: an overview. Pearson. Boston. 2009. [6] Cohen, W.A Computer Scientist’s Guide to Cell Biology. Springer, Heidelberg. 2007. [7] Colburn, T. "Methodology of Computer Science". The Blackwell Guide to the Philosophy of Computing and Information, Luciano Floridi (ed.), Malden: Blackwell, pp. 318–326. 2004. [8] Colburn, T.R. Philosophy and Computer Science, Explorations in Philosophy. Series, New York: M.E. Sharpe. 2000. [9] Denning, P.J. "What is Experimental Computer Science?" Communications of the ACM 23(10): 534–544. 1980. [10] Denning, P.J. "The Science of Computing: What is computer science." American Scientist 73(1): 16–19. 1985. [11] Fetzer, J.H. "Program Veri…cation: The Very Idea." Communications of the ACM 31(9): 1048–1063. 1988. [12] Fernandez. M. Programming Languages and Operational Semantics: An Introduction. Oxford. 2007. [13] Gabbay, D et. all. Handbook of Logic in Computer Science. Oxford University Press. 1994. [14] Garey, M.R., Johnson, D.S. Computers and Intractability.. Freeman. 1979. San Francisco. [15] Girard, Jean-Yves. "Linear Logic." Theoretical Computer Science, 50 1-1. 1987. [16] Harel, D. Kozen, D. Tiuryn, J. Dynamic Logic. MIT press. Cambridge, Mass. 2000. [17] Hartmanis, J. "Some Observations about the Nature of Computer Science." Lecture Notes in Computer Science 761. Springer. Shyamasundar, R.K. (ed.): 1–12. 1993. [18] Hoare, T. "The Ideal of Program Correctness." Third Computer Journal Lecture. Comput. J. 50(3): 254-260 2007. [19] Hoare, T. Science and Engineering: A Collusion of Cultures. Dependable Systems and Networks, 2007. 37th Annual IEEE/IFIP International Conference. [20] Kuhn, T,S. The Structure of Scienti…c Revolutions, 1st. ed., Chicago: Univ. of Chicago Pr., 1962. 14
[21] Kripke, S. Wittgenstein on Rules and Private Language. Harvard University Press. 1982. [22] Milne, R. and Strachey, C. A Theory of Programming Language Semantics, New York, NY: Halsted Press. 1977. [23] Moor, J. H. "Three Myths of Computer Science." The British Journal for the Philosophy of Science 29(3): 213–222. 1980. [24] Noergaard, T. Embedded Systems Architecture: A Comprehensive Guide for Engineers and Programmers. Springer, New York. 2005. [25] Pierce, B, C. Types and Programming Languages. MIT press. Mass. 2002. [26] Rapaport, W.J. "Implementation is Semantic Interpretation: Further Thoughts." Journal of Experimental and Theoretical Arti…cial Intelligence 17(4): 385–417. 2005. [27] Restall, G. An Introduction to Substructural Logics, Routledge. London. 2000. [28] Russell, S.J. Norvig, P. Arti…cial Intelligence: Modern Approach. Pearson. 1995. London. [29] Seydel, R, U. Tools for Computational Finance. Universitext. 4th ed. 2009. [30] Shapiro. Philosophy of Mathematics: Structure and Ontology. Oxford. 2004. [31] Smith, B.C. "Limits of Correctness in Computers." Computerization and Controversy, Kling, R. (ed.), Morgan Kaufman, pp. 810–825. 1996. [32] Stoy, J. The Scott-Strachey Approach to Programming Language Semantics. MIT Press, 1977. [33] Tennent, R.D. Semantics of Programming Languages. Prentice-Hall International, London, 1991 [34] Turner, R. "Understanding Programming Languages." Minds and Machines 17(2): 129-133. 2007. [35] Turner. R. "Lazy Theories of Operations and Types." Journal of Logic and Comp., 3, 77–102, 1993. [36] Turner, R. "Weak Theories of Operations and Types." Journal of Logic and Comp., 6, 5–31, 1996. [37] Turner, R. "Type inference for set theory." Theoretical Computer Science, 266, 951–974, [38] Watt, D. A. Programming Language Design Concepts. Wiley. Chichester, UK. 2004. 15
[39] Wegner, P. Programming Languages, Information Structures, and Machine Organization. McGraw Hill. 1968. [40] Wittgenstein, L. Philosophical Investigations. Blackwell Publishing. Oxford. 1953.
16
