11-logprog

11-logprog - Logic Programming Having just studied the use...

Info iconThis preview shows pages 1–6. Sign up to view the full content.

View Full Document Right Arrow Icon
Logic Programming Having just studied the use of Alloy as a tool for checking specifications of software systems, we turn our attention in this module to a related question: whether, once we have a sufficiently detailed specification for a software system, we might be able to simply “execute” the specification as a program that meets it. More realistically, the question we shall explore is whether specifications for programs can be “compiled” or otherwise translated into specification-compliant executable code without any additional coding burden. 1
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Short answer: no We must, of course, be reasonable about our expectations! There is no way we could expect that the brief characterization of file systems we gave in the last module provides sufficient information to derive a working file system implemented on actual hardware. To begin with, we omitted many features possessed by real file systems: user permissions, handling of concurrent reads/writes, etc. In principle, we could enhance the model to incorporate these. But what about actually interacting with a disk drive? Could this behaviour be derived? Maybe, but not without a lot of help! 2
Background image of page 2
Long answer: read on In module 8, we discussed the axiom schema of replacement, which speaks of binary predicates P such that if P ( x,y ) holds, then the value of x uniquely determines the value of y . For example, we might have P ( x,y ) = ( x = 1 y = 2) ( x = 3 y = 4) . Then from the knowledge that x = 1 , we can derive y = 2 ; similarly, if we know that x = 3 (and also that P holds, of course), then we can conclude y = 4 . There is clearly a notion of computation going on here. In treating x as an “input”, we can obtain y as an “output”. Indeed, we noted that predicates P that behave as above could be regarded as functions. 3
Background image of page 3

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Can we push this idea further? What if we start considering less contrived predicates? For example, what if a predicate P could be interpreted as follows: P ( x,y ) = x is a list of numbers, and y is the reversal of x . Again, the value of x uniquely determines y . Assuming we could find a formula expressing P , if we then “plug in” some list for x , could we derive its reversal in y ? If so, then we have just “executed” a formula! Also note: in this example, the value of y also uniquely determines the value of x . Keep this in mind. ... 4
Background image of page 4
If we want to create a system for deriving y given x and P ( x,y ) , we first must be more precise about just what it is we would like the system to do. In a more general setting, we are given a set φ 1 ,...,φ m as premises, inputs x 1 ,...,x n , and an ( n + p ) -ary predicate P , and we wish to find a y 1 ,...,y p such that φ 1 ,...,φ m P ( x 1 ,...,x n ,y 1 ,...,y p ) . But there are technical challenges that stand in the way of
Background image of page 5

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Image of page 6
This is the end of the preview. Sign up to access the rest of the document.

Page1 / 53

11-logprog - Logic Programming Having just studied the use...

This preview shows document pages 1 - 6. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online