DOCSLIB.ORG

What Is Logic Programming? the Paradigm History

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
What Is Logic Programming? the Paradigm History What is Logic Programming? There are many (overlapping) perspectives on logic programming – Computations as Deduction – Theorem Proving – Non-procedural Programming – Algorithms minus Control – A Very High Level Programming Language – A Procedural Interpretation of Declarative Specifications The Paradigm History • An important programming paradigm is to • Logic Programming has roots going back to early express a program as a set of rules AI researchers like John McCarthy in the 50s & 60s • The rules are independent and often • Alain Colmerauer (France) designed Prolog as the first LP language in the early 1970s unordered • Bob Kowalski and colleagues in the UK evolved the • CFGs can be thought of as a rule based language to its current form in the late 70s system • It’s been widely used for many AI systems, but also • We’ll take a brief look at a particular sub- for systems that need a fast, efficient and clean rule paradigm, Logic Programming based engine • And at Prolog, the most successful of the • The prolog model has also influenced the database logic programming languages community – see datalog 1 Computation as Deduction Theorem Proving • Logic programming offers a slightly different paradigm for • Logic Programming uses the notion of an automatic computation: computation is logical deduction theorem prover as an interpreter. • It uses the language of logic to express data and programs. Forall X, Y: X is the father of Y if X is a parent of Y and X is male • The theorem prover derives a desired solution from • Current logic programming languages use first order logic an initial set of axioms. (FOL) which is often referred to as first order predicate • The proof must be a "constructive" one so that more calculus (FOPC). than a true/false answer can be obtained • The first order refers to the constraint that we can quantify • E.G. The answer to (i.e. generalize) over objects, but not over functions or exists x such that x = sqrt(16) relations. We can express "All elephants are mammals” but not • should be "for every continuous function f, if n<m and f(n)<0 and f(m) x = 4 or x = -4 >0 then there exists an x such that n<x<m and f(x)=0" • rather than true Non-procedural Programming A Declarative Example • Logic Programming languages are non-procedural • Here’s a simple way to specify what programming languages has to be true if X is the smallest number in a • A non-procedural language one in which one list of numbers L specifies what needs to be computed but not how it 1. X has to be a member of the list L is to be done 2. There can be list member X2 such that X2<X • That is, one specifies: • We need to say how we determine that some – the set of objects involved in the computation X is a member of a list – the relationships which hold between them – the constraints which must hold for the problem to be 1. No X is a member of the empty list solved 2. X is a member of list L if it is equal to L’s head • and leaves it up the the language interpreter or 3. X is a member of list L if it is a member of L’s compiler to decide how to satisfy the constraints tail. 2 A Simple Prolog Model Nomenclature and Syntax Think of Prolog as a system which has a database • A prolog rule is called a clause composed of two components: • A clause has a head, a neck and a body: • facts: statements about true relations which hold between father(X,Y) :- parent(X,Y) , male(X) . particular objects in the world. For example: parent(adam, able). % adam is a parent of able head neck body parent(eve, able). % eve is a parent of able • the head is a single predicate -- the rule's conclusion male(adam). % adam is male. • The body is a a sequence of zero or more predicates • rules: statements about relations between objects in the that are the rule's premise or condition world which use variables to express generalizations % X is the father of Y if X is a parent of Y and X is male • An empty body means the rule’s head is a fact. father(X,Y) :- parent(X, Y), male(X). • note: % X is a sibling of Y if X and Y share a parent – read :- as IF sibling(X,Y) :- parent(P,X), parent(P,Y) – read , as AND between predicates – a . marks the end of input Prolog Database Queries • We also have queries in addition to having facts and rules parent(adam,able) • The Prolog REPL interprets input as queries parent(adam,cain) Facts comprising the male(adam) “extensional database” • A simple query is just a predicate that might ... have variables in it: – parent(adam, cain) father(X,Y) :- parent(X,Y), – parent(adam, X) male(X). Rules comprising the sibling(X,Y) :- ... “intensional database” 3 Extensional vs. Intensional Running prolog The terms extensional and Prolog Database • A good free version of prolog is swi-prolog intensional are borrowed from the language philosophers use parent(adam,able) Facts comprising the • GL has a commercial version (sicstus prolog) for epistemology. parent(adam,cain) male(adam) “extensional database” you can invoke with the command “sicstus” • Extension refers to whatever extends, i.e., “is ... [finin@linux2 ~]$ sicstus quantifiable in space as well as in time”. father(X,Y) :- parent(X,Y), SICStus 3.7.1 (Linux-2.2.5-15-i686): Wed Aug 11 16:30:39 CEST 1999 • Intension is an antonym of extension, Rules comprising the male(X). “intensional database” Licensed to umbc.edu referring to “that class of existence which may sibling(X,Y) :- ... be quantifiable in time but not in space.” | ?- assert(parent(adam,able)). • NOT intentional with a “t”, which has to do yes with “will, volition, desire, plan, …” | ?- parent(adam,P). For KBs and DBs we use Epistemology is “a branch of philosophy P = able ? • extensional to refer to that which is explicitly that investigates the origin, nature, represented (e.g., a fact), and methods, and limits of knowledge” yes • intensional to refer to that which is represented abstractly, e.g., by a rule of | ?- inference. A Simple Prolog Session A Prolog Session | ?- [user]. | ?- mother(eve,Who). | female(eve). Who = cain | ?- assert(parent(adam,able)). | parent(adam,cain). yes | ?- parent(X,able). | parent(eve,cain). | ?- trace, mother(Who,cain). yes X = adam ; | father(X,Y) :- parent(X,Y), male(X). (2) 1 Call: mother(_0,cain) ? | ?- assert(parent(eve,able)). X = eve ; | mother(X,Y) :- parent(X,Y), female(X). (3) 2 Call: parent(_0,cain) ? yes no | ^Zuser consulted 356 bytes 0.0666673 (3) 2 Exit: parent(adam,cain) | ?- assert(male(adam)). | ?- parent(X,able) , male(X). sec. (4) 2 Call: female(adam) ? yes X = adam ; yes (4) 2 Fail: female(adam) | ?- mother(Who,cain). | ?- parent(adam,able). no (3) 2 Back to: parent(_0,cain) ? yes Who = eve (3) 2 Exit: parent(eve,cain) yes | ?- parent(adam,X). (5) 2 Call: female(eve) ? X = able (5) 2 Exit: female(eve) (2) 1 Exit: mother(eve,cain) yes Who = eve yes 4 trace,sibling(X,Y). (14) 3 Back to: parent(eve,able) ? (2) 1 Call: sibling(_0,_1) ? (14) 3 Fail: parent(eve,able) [finin@linux2 ~]$ more genesis.pl (3) 2 Call: father(_65643,_0) ? (13) 2 Back to: mother(eve,able) ? Program files | ?- [user]. (4) 3 Call: parent(_65643,_0) ? (13) 2 Fail: mother(eve,able) % prolog example (4) 3 Exit: parent(adam,able) (12) 3 Back to: female(eve) ? | sibling(X,Y) :- (5) 3 Call: male(adam) ? (12) 3 Fail: female(eve) (5) 3 Exit: male(adam) (10) 3 Back to: parent(_65644,able) ? % facts | father(Pa,X), (3) 2 Exit: father(adam,able) (10) 3 Fail: parent(_65644,able) Typically you put your assertions (fact (6) 2 Call: father(adam,_1) ? (9) 2 Back to: mother(_65644,able) ? male(adam). | father(Pa,Y), (7) 3 Call: parent(adam,_1) ? (9) 2 Fail: mother(_65644,able) and rules) into a file and load it (7) 3 Exit: parent(adam,able) (8) 3 Back to: male(adam) ? | ?- [genesis]. female(eve). | mother(Ma,X), (8) 3 Call: male(adam) ? (8) 3 Fail: male(adam) {consulting /afs/umbc.edu/users/f/i/finin/home/genesis.pl...} (8) 3 Exit: male(adam) (7) 3 Back to: parent(adam,_1) ? parent(adam,cain). | mother(Ma,Y), (6) 2 Exit: father(adam,able) (7) 3 Exit: parent(adam,cain) {/afs/umbc.edu/users/f/i/finin/home/genesis.pl consulted, 0 msec 2720 (9) 2 Call: mother(_65644,able) ? (18) 3 Call: male(adam) ? bytes} parent(eve,cain). | not(X=Y). (10) 3 Call: parent(_65644,able) ? (18) 3 Exit: male(adam) yes parent(adam,able). (10) 3 Exit: parent(adam,able) (6) 2 Exit: father(adam,cain) | ?- male(adam). (11) 3 Call: female(adam) ? (19) 2 Call: mother(_65644,able) ? ^Zuser consulted 152 bytes 0.0500008 sec. yes parent(eve,able). (11) 3 Fail: female(adam) (20) 3 Call: parent(_65644,able) ? yes (10) 3 Back to: parent(_65644,able) ? (20) 3 Exit: parent(adam,able) | ?- sibling(P1, P2). (10) 3 Exit: parent(eve,able) (21) 3 Call: female(adam) ? P1 = cain, % rules | ?- sibling(X,Y). (12) 3 Call: female(eve) ? (21) 3 Fail: female(adam) P2 = cain ? ; (12) 3 Exit: female(eve) (20) 3 Back to: parent(_65644,able) ? father(X,Y) :- P1 = cain, X = able (9) 2 Exit: mother(eve,able) (20) 3 Exit: parent(eve,able) (13) 2 Call: mother(eve,able) ? (22) 3 Call: female(eve) ? P2 = able ? ; parent(X,Y), (14) 3 Call: parent(eve,able) ? (22) 3 Exit: female(eve) P1 = cain, Y = cain ; male(X).
Load more

Recommended publications
  • Functional and Logic Programming - Wolfgang Schreiner
    COMPUTER SCIENCE AND ENGINEERING - Functional and Logic Programming - Wolfgang Schreiner FUNCTIONAL AND LOGIC PROGRAMMING Wolfgang Schreiner Research Institute for Symbolic Computation (RISC-Linz), Johannes Kepler University, A-4040 Linz, Austria, [email protected]. Keywords: declarative programming, mathematical functions, Haskell, ML, referential transparency, term reduction, strict evaluation, lazy evaluation, higher-order functions, program skeletons, program transformation, reasoning, polymorphism, functors, generic programming, parallel execution, logic formulas, Horn clauses, automated theorem proving, Prolog, SLD-resolution, unification, AND/OR tree, constraint solving, constraint logic programming, functional logic programming, natural language processing, databases, expert systems, computer algebra. Contents 1. Introduction 2. Functional Programming 2.1 Mathematical Foundations 2.2 Programming Model 2.3 Evaluation Strategies 2.4 Higher Order Functions 2.5 Parallel Execution 2.6 Type Systems 2.7 Implementation Issues 3. Logic Programming 3.1 Logical Foundations 3.2. Programming Model 3.3 Inference Strategy 3.4 Extra-Logical Features 3.5 Parallel Execution 4. Refinement and Convergence 4.1 Constraint Logic Programming 4.2 Functional Logic Programming 5. Impacts on Computer Science Glossary BibliographyUNESCO – EOLSS Summary SAMPLE CHAPTERS Most programming languages are models of the underlying machine, which has the advantage of a rather direct translation of a program statement to a sequence of machine instructions. Some languages, however, are based on models that are derived from mathematical theories, which has the advantages of a more concise description of a program and of a more natural form of reasoning and transformation. In functional languages, this basis is the concept of a mathematical function which maps a given argument values to some result value.
    [Show full text]
  • Belgium a Logic Meta-Programming Framework for Supporting The
    Vrije Universiteit Brussel - Belgium Faculty of Sciences In Collaboration with Ecole des Mines de Nantes - France 2003 ERSITEIT IV B N R U U S E S J I E R L V S C S I E A N R B T E IA N VIN TE CERE ECOLE DES MINES DE NANTES A Logic Meta-Programming Framework for Supporting the Refactoring Process A Thesis submitted in partial fulfillment of the requirements for the degree of Master of Science in Computer Science (Thesis research conducted in the EMOOSE exchange) By: Francisca Mu˜nozBravo Promotor: Prof. Dr. Theo D’Hondt (Vrije Universiteit Brussel) Co-Promotors: Dr. Tom Tourw´eand Dr. Tom Mens (Vrije Universiteit Brussel) Abstract The objective of this thesis is to provide automated support for recognizing design flaws in object oriented code, suggesting proper refactorings and performing automatically the ones selected by the user. Software suffers from inevitable changes throughout the development and the maintenance phase, and this usually affects its internal structure negatively. This makes new changes diffi- cult to implement and the code drifts away from the original design. The introduced structural disorder can be countered by applying refactorings, a kind of code transformation that improves the internal structure without affecting the behavior of the application. There are several tools that support applying refactorings in an automated way, but little help for deciding where to apply a refactoring and which refactoring could be applied. This thesis presents an advanced refactoring tool that provides support for the earlier phases of the refactoring process, by detecting and analyzing bad code smells in a software application, proposing appropriate refactorings that solve these smells, and letting the user decide which one to apply.
    [Show full text]
  • Logic Programming Lecture 19 Tuesday, April 5, 2016 1 Logic Programming 2 Prolog
    Harvard School of Engineering and Applied Sciences — CS 152: Programming Languages Logic programming Lecture 19 Tuesday, April 5, 2016 1 Logic programming Logic programming has its roots in automated theorem proving. Logic programming differs from theorem proving in that logic programming uses the framework of a logic to specify and perform computation. Essentially, a logic program computes values, using mechanisms that are also useful for deduction. Logic programming typically restricts itself to well-behaved fragments of logic. We can think of logic programs as having two interpretations. In the declarative interpretation, a logic pro- gram declares what is being computed. In the procedural interpretation, a logic program program describes how a computation takes place. In the declarative interpretation, one can reason about the correctness of a program without needing to think about underlying computation mechanisms; this makes declarative programs easier to understand, and to develop. A lot of the time, once we have developed a declarative program using a logic programming language, we also have an executable specification, that is, a procedu- ral interpretation that tells us how to compute what we described. This is one of the appealing features of logic programming. (In practice, executable specifications obtained this way are often inefficient; an under- standing of the underlying computational mechanism is needed to make the execution of the declarative program efficient.) We’ll consider some of the concepts of logic programming by considering the programming language Prolog, which was developed in the early 70s, initially as a programming language for natural language processing. 2 Prolog We start by introducing some terminology and syntax.
    [Show full text]
  • Chapter 11. Knowledge Representation and Reasoning the Quest for Artificial Intelligence, Nilsson, N
    Chapter 11. Knowledge Representation and Reasoning The Quest for Artificial Intelligence, Nilsson, N. J., 2009. Lecture Notes on Artificial Intelligence Summarized by Ha, Jung-Woo and Lee, Beom-Jin Biointelligence Laboratory School of Computer Science and Engineering Seoul National Univertisy http://bi.snu.ac.kr Contents 11.1 Deductions in Symbolic Logic Deductions in Symbolic Logic 11.2 The Situation Calculus The Situation Calculus 11.3 Logic Programming Logic Programming 11.4 Semantic Networks Semantic Networks 11.5 Scripts and Frames Scripts and Frames Appendix © 2016, SNU CSE Biointelligence Lab., http://bi.snu.ac.kr 2 Overview Methods for knowledge representation and reasoning from Mid-1960s and Mid-1970s Symbolic logic and its deductions Predicate calculus For proving theories Situation calculus Logic programming: PROLOG Sematic networks: HAM, MEMS, MENTAL Script and Frames © 2016, SNU CSE Biointelligence Lab., http://bi.snu.ac.kr 3 Introduction Knowledge For intelligent system The mean to draw conclusion from or act on Knowledge representation Procedural Coordinate and control the specific action (ex. hitting a tennis ball) Programs using the knowledge Specific task program Declarative Declarative sentence (I am a 25 years old) Symbolic structures General task program © 2016, SNU CSE Biointelligence Lab., http://bi.snu.ac.kr 4 Chapter 11. Knowledge Representation and Reasoning 11.1 Deductions in Symbolic Logic © 2016, SNU CSE Biointelligence Lab., http://bi.snu.ac.kr 5 Deductions in Symbolic Logic The predicate calculus From Aristotle to G. Boole and McCarthy Ex. Aristotle syllogism 1. (∀ x)[Man(x) ⊃ Mortal(x)] (The expression “(∀ x)” is a way of writing “for all x”; and the expression “⊃” is a way of writing "implies that." “Man(x)” is a way of writing “x is a man”; and “Mortal(x)” is a way of writing “x is mortal.” Thus, the entire expression is a way of writing “for all x, x is a man implies that x is mortal” or, equivalently, “all men are mortal.”) 2.
    [Show full text]
  • Towards Flexible Goal-Oriented Logic Programming
    FACULTY OF SCIENCES Towards Flexible Goal-Oriented Logic Programming ir. Benoit Desouter Dissertation submitted in partial fulfillment of the requirements for the degree of Doctor of Computer Science Supervisors: prof. dr. ir. Tom Schrijvers prof. dr. ir. Marko van Dooren Department of Applied Mathematics, Computer Science and Statistics Faculty of Sciences, Ghent University ii Acknowledgments As it feels more natural to thank people in the language that we have used on a daily basis during the journey towards completing this PhD thesis, I'll use Dutch for most of the next few pages. In de eerste plaats wil ik mijn promotoren Tom en Marko bedanken. Tom, bedankt voor het geduld als ik occasioneel iets maar half begreep, en om er altijd vertrouwen in te blijven hebben. Je hebt me heel wat kansen aangereikt, waardoor ik van heel wat onderwerpen iets heb opgestoken. Marko, hoewel je er pas halverwege bijkwam, toonde je al snel interesse voor het onderwerp en heb je er vanuit je eigen expertise heel wat aan toegevoegd. Je deur stond altijd voor me open als ik even een tussentijdse statusupdate wou geven. Bedankt voor de babbels over vanalles en nog wat, en om me grondig te betrekken bij het geven van Programmeren 1. Ik heb nog heel wat bijgeleerd over objec- tori¨entatie door jouw visie, slides en codevoorbeelden. Daarnaast ook bedankt om mijn lokale LATEX-goeroe te zijn: niettegenstaande ik LATEX al tien jaar lang gebruik, heb ik voor het precies goed krijgen van deze thesis heel wat nieuwe pakketten en trucjes moeten gebruiken, met regelmatig vreemde out- put of cryptische foutmeldingen tot gevolg die ik niet altijd alleen kon oplossen | of het zou me op zijn minst veel meer tijd gekost hebben.
    [Show full text]
  • Chapter 1 Basic Principles of Programming Languages
    Chapter 1 Basic Principles of Programming Languages Although there exist many programming languages, the differences among them are insignificant compared to the differences among natural languages. In this chapter, we discuss the common aspects shared among different programming languages. These aspects include: programming paradigms that define how computation is expressed; the main features of programming languages and their impact on the performance of programs written in the languages; a brief review of the history and development of programming languages; the lexical, syntactic, and semantic structures of programming languages, data and data types, program processing and preprocessing, and the life cycles of program development. At the end of the chapter, you should have learned: what programming paradigms are; an overview of different programming languages and the background knowledge of these languages; the structures of programming languages and how programming languages are defined at the syntactic level; data types, strong versus weak checking; the relationship between language features and their performances; the processing and preprocessing of programming languages, compilation versus interpretation, and different execution models of macros, procedures, and inline procedures; the steps used for program development: requirement, specification, design, implementation, testing, and the correctness proof of programs. The chapter is organized as follows. Section 1.1 introduces the programming paradigms, performance, features, and the development of programming languages. Section 1.2 outlines the structures and design issues of programming languages. Section 1.3 discusses the typing systems, including types of variables, type equivalence, type conversion, and type checking during the compilation. Section 1.4 presents the preprocessing and processing of programming languages, including macro processing, interpretation, and compilation.
    [Show full text]
  • An Introduction to Prolog
    Appendix A An Introduction to Prolog A.1 A Short Background Prolog was designed in the 1970s by Alain Colmerauer and a team of researchers with the idea – new at that time – that it was possible to use logic to represent knowledge and to write programs. More precisely, Prolog uses a subset of predicate logic and draws its structure from theoretical works of earlier logicians such as Herbrand (1930) and Robinson (1965) on the automation of theorem proving. Prolog was originally intended for the writing of natural language processing applications. Because of its conciseness and simplicity, it became popular well beyond this domain and now has adepts in areas such as: • Formal logic and associated forms of programming • Reasoning modeling • Database programming • Planning, and so on. This chapter is a short review of Prolog. In-depth tutorials include: in English, Bratko (2012), Clocksin and Mellish (2003), Covington et al. (1997), and Sterling and Shapiro (1994); in French, Giannesini et al. (1985); and in German, Baumann (1991). Boizumault (1988, 1993) contain a didactical implementation of Prolog in Lisp. Prolog foundations rest on first-order logic. Apt (1997), Burke and Foxley (1996), Delahaye (1986), and Lloyd (1987) examine theoretical links between this part of logic and Prolog. Colmerauer started his work at the University of Montréal, and a first version of the language was implemented at the University of Marseilles in 1972. Colmerauer and Roussel (1996) tell the story of the birth of Prolog, including their try-and-fail experimentation to select tractable algorithms from the mass of results provided by research in logic.
    [Show full text]
  • Neural Logic Framework for Digital Assistants
    MEng Individual Project Imperial College London Department of Computing Neural Logic Framework for Digital Assistants Supervisor: Prof. Alessandra Russo Author: Nuri Cingillioglu Second Marker: Dr. Krysia Broda June 16, 2017 Abstract Digital assistants are becoming ubiquitous with consumers across mobile platforms help- ing with everyday tasks. The natural language interface of most assistants are built on machine learning based intent parsing techniques. This design cannot handle higher level abstract reasoning such as defaults while logic programs can incorporate them. In this project we present Kevin, a digital personal assistant with a logical framework built on top of neural networks to provide a flexible execution environment while har- nessing the capabilities of machine learning at a lower level. Kevin demonstrates natural language based logical constructs such as unification and resolution with integrated neural network information retrieval. Acknowledgements I would like to thank: • my parents for their wholehearted support, endless love and perpetual encourage- ment. • my supervisor Prof. Alessandra Russo for giving me this opportunity by accepting the project proposal and allowing me to explore the topic as well as her PhD student Mark Law for his feedback. • my personal tutor Dr. Alistair Donaldson for his support and advice for the years. • my friends for their companionship and solace throughout my degree. Contents 1 Introduction 11 1.1 Motivation.................................... 11 1.2 Objectives.................................... 12 1.3 Challenges.................................... 12 1.4 Contributions.................................. 13 2 Related Work 14 2.1 Natural Language Interactions......................... 14 2.1.1 Turing Test............................... 14 2.1.2 Conversational Agents......................... 15 2.2 Domain-specific Assistants........................... 17 2.2.1 PANDA: Virtual assistant for in-car child entertainment.....
    [Show full text]
  • 9B. Combining Logic Programs with Object-Oriented Representation
    9b. Combining Logic Programs with Object-Oriented Representation Outline • Limitations of frames & description logics • Early hybrid KR&R systems – Krypton • Recent trends in hybrid KR&R systems – Description graphs – F-Logic Limitation of Frames & Description Logics • Polyadic predicates – Relations with arity greater than two • A is between B and C • Limited relational expressivity – DLs can model only domains where objects are connected in a tree like manner • ``an uncle of a person is a brother of that person’s father’’ • Disjunction – Many concepts have disjunctively defined definitions • A person is legally employable if they are of employable age, and they are either a legal immigrant or US citizen • Negation and relative complements – Many facts are inherently negative • Under no circumstances is it illegal to drive on the shoulder of a road • Concepts defined using conditionals – An animal is dangerous to humans if it attacks them when near by • Equivalence to two other concepts – A dinner wine is proper if it is red whenever the main dish is red meat or is tomato based or else if it is white wine A more complete list is available in ``Two theses of knowledge representation: language restrictions, taxonomic classification, and the utility of representation services’’ by Doyle and Patil, AIJ, 1991 Krypton • Knowledge representation has two components – Terminological component (Tbox) – Assertional component (ABox) • Functional specification of a Knowledge Base – Instead of focusing on ``What structures should the system maintain
    [Show full text]
  • A Survey on Teaching and Learning Recursive Programming
    Informatics in Education, 2014, Vol. 13, No. 1, 87–119 87 © 2014 Vilnius University A Survey on Teaching and Learning Recursive Programming Christian RINDERKNECHT Department of Programming Languages and Compilers, Eötvös Loránd University Budapest, Hungary E-mail: [email protected] Received: July 2013 Abstract. We survey the literature about the teaching and learning of recursive programming. After a short history of the advent of recursion in programming languages and its adoption by programmers, we present curricular approaches to recursion, including a review of textbooks and some programming methodology, as well as the functional and imperative paradigms and the distinction between control flow vs. data flow. We follow the researchers in stating the problem with base cases, noting the similarity with induction in mathematics, making concrete analogies for recursion, using games, visualizations, animations, multimedia environments, intelligent tutor- ing systems and visual programming. We cover the usage in schools of the Logo programming language and the associated theoretical didactics, including a brief overview of the constructivist and constructionist theories of learning; we also sketch the learners’ mental models which have been identified so far, and non-classical remedial strategies, such as kinesthesis and syntonicity. We append an extensive and carefully collated bibliography, which we hope will facilitate new research. Key words: computer science education, didactics of programming, recursion, tail recursion, em- bedded recursion, iteration, loop, mental models. Foreword In this article, we survey how practitioners and educators have been teaching recursion, both as a concept and a programming technique, and how pupils have been learning it. After a brief historical account, we opt for a thematic presentation with cross-references, and we append an extensive bibliography which was very carefully collated.
    [Show full text]
  • A Meta-Programming Approach to Realizing Dependently Typed Logic Programming
    A Meta-Programming Approach to Realizing Dependently Typed Logic Programming Zach Snow David Baelde Gopalan Nadathur Computer Science and Eng. Computer Science and Eng. Computer Science and Eng. University of Minnesota University of Minnesota University of Minnesota [email protected] [email protected] [email protected] ABSTRACT in an elegant way through type dependencies, and they for- Dependently typed lambda calculi such as the Logical Frame- malize the authentication of proofs through type-checking. work (LF) can encode relationships between terms in types Such calculi can also be assigned a logic programming in- and can naturally capture correspondences between formu- terpretation by exploiting the well-known isomorphism be- las and their proofs. Such calculi can also be given a logic tween formulas and types [12]. The Twelf system [17] that programming interpretation: the Twelf system is based on we consider in this paper exploits this possibility relative such an interpretation of LF. We consider here whether a to LF. As such, it has been used successfully in specifying conventional logic programming language can provide the and prototyping varied formal systems and mechanisms have benefits of a Twelf-like system for encoding type and proof- also been built into it to reason about these specifications. and-formula dependencies. In particular, we present a sim- Predicate logics provide the basis for logic programming ple mapping from LF specifications to a set of formulas in languages that are also capable of encoding rule-based spec- the higher-order hereditary Harrop (hohh) language, that ifications. Within this framework, the logic of higher-order relates derivations and proof-search between the two frame- hereditary Harrop (hohh) formulas [13] that underlies the works.
    [Show full text]
  • Logic Programming Languages
    Programming Languages Lecture 8: Logic Programming Languages Benjamin J. Keller Department of Computer Science, Virginia Tech Blacksburg, Virginia 24061 USA Programming Languages | Lecture 16 | Logic Programming Languages 2 History and Goals of Logic Programming • Competitor to LISP for AI programming in 80's • Adopted by Japanese for Fifth Generation Computing Project (Prolog). • What is logic programming? { Programming based on the notion of logical deduction in symbolic logic. { Implementation typically based on mechanisms for automatic theorem proving. Programming Languages | Lecture 16 | Logic Programming Languages 3 History and Goals of Logic Programming (cont) • \A constructive proof that for every list L there is a corresponding sorted list S composed of the same elements as L yields an algorithm for sorting a list." • Philosophy is shared by others not working on \logic programming" { Constable at Cornell, Martin-L¨of in Sweden, Calculus of Constructions group in France. { These groups want to extract (more traditional) program from constructive proofs. • Very-High-Level Languages - non-procedural • State what must be done, not how to do it. Idea is to separate logic from control. Programming Languages | Lecture 16 | Logic Programming Languages 4 Introduction to Prolog • Prolog (PROgramming in LOGic), first and most important logic programming language. • Developed in 1972 by Alain Colmerauer in Marseilles. • Relational rather than functional programming language • Often best to start out as thinking of Prolog in terms of language for working with a data base. Programming Languages | Lecture 16 | Logic Programming Languages 5 Pure Prolog • Three types of statements: 1. Facts (or hypotheses): father(albert,jeffrey). 2. Rules (or conditions): grandparent(X,Z) :- parent(X,Y),parent(Y,Z).
    [Show full text]