COP 4020 Lecture -*- Outline -*- * Relational Programming (Ch 9) Based on Peter van Roy and Seif Haridi's book, "Concepts, Techniques, and Models of Computer Programming" (MIT Press, 2004), where all references that are not otherwise attributed are found. ** Motivation ------------------------------------------ MOTIVATIONS FOR RELATIONAL PROGRAMMING ------------------------------------------ ... see questions below *** programming is difficult, expensive Q: Why is programming so hard? Special-purpose training not oriented to help end users conceptual gap caused by concern for efficiency Q: What approaches might solve this problem? Domain specific languages (or end-user languages)(Excel, ...) Reuse/frameworks (higher-order functional, OOP) (JDK) executable specifications or search (relational, logic prog) model-driven development is a compromise, very high level specifications are used to partially derive executable code Q: What are the steps in building a computer system to do some job? specifying what is to be done + detailed design and coding + maintenance (how does maintenance work?) Q: Can we separate them? Which could we automate? yes, the detailed design and coding perhaps, if we could execute specifications *** rapid prototyping Q: How do we know if we're building the right system? the idea of rapid prototyping is to quickly turn around specifications into prototypes to "hone in" on the "right" system. Q: What would help us do that better? if we could execute specifications Q: What are the costs we care about in rapid prototyping? costs of building the prototype time to getting feedback ** Goals Q: So what should our goals for declarative programming be, to solve the problems that motivate the paradigm? ------------------------------------------ GOALS OF RELATIONAL PROGRAMMING ------------------------------------------ ... WRITE programs efficiently (vs. running efficiently) execute specifications, declarative (what, not how) -only state constraints on result e.g., x is-in l if x is the head of l x is-in l if x is-in the tail of l -no explicit (or separate) directions about data structures, algorithms ** relational (logic) programming *** idea ------------------------------------------ RELATIONAL PROGRAMMING (CH. 9) idea: procedures are relations - zero results, one result, or more - arguments can be both inputs and outputs varies with different calls Example (from section 9.3.3) \insert 'SolveFirst.oz' \insert 'SolveAll.oz' declare proc {RAppend ?A ?B ?C} choice A=nil B=C [] local As Cs X in A=X|As C=X|Cs {RAppend As B Cs} end end end % Forward use {Browse {SolveFirst proc {$ S} Z=S in {RAppend [3 4] [5 6] Z} end}} % Backward use {Browse {SolveFirst proc {$ S} X=S in {RAppend X [2 3] [1 2 3]} end}} {Browse {SolveFirst proc {$ S} Y=S in {RAppend [3 4] Y [3 4 5 6]} end}} % Determine combinations of arguments {Browse {SolveAll proc {$ S} X#Y=S in {RAppend X Y [1 2 3]} end}} {Browse {SolveFirst proc {$ S} Y#Z=S in {RAppend [1 2] Y Z} end}} {Browse {List.take {Solve proc {$ S} X#Z=S in {RAppend X [3 4] Z} end} 3}} % Check if all arguments fit together {Browse {SolveFirst proc {$ S} {RAppend [1 2] [3 4] [1 2 3 4]} S=unit end}} ------------------------------------------ See RAppend.oz RAppendTest.oz Q: So what's a "result" of a procedure? a set of bindings for the argument variable identifiers (a substitution) The primitive choice, gives a "choice point" for the search. Solve gives a lazy list of solutions, it encapsulates search (found in the book's web site as the supplements file) more on these later... *** uses ------------------------------------------ WHEN TO USE RELATIONAL PROGRAMMING - For specifications - as an exploratory tool - when the search space is small ------------------------------------------ Q: Why is this good for specifications? time and efficiency don't matter Q: Why is this good for exploratory programming? you save time in programming Q: Why is this good when the search space is small? then it won't take too long The authors note that when the search space is larger, more sophisticated techniques are needed (e.g., constraint-solving, see chapter 12)