The Logtalk Handbook Release V3.22.0

Total Page:16

File Type:pdf, Size:1020Kb

The Logtalk Handbook Release V3.22.0 The Logtalk Handbook Release v3.22.0 Paulo Moura Dec 18, 2018 CONTENTS: 1 User Manual 1 1.1 Declarative object-oriented programming.............................1 1.2 Main features.............................................2 1.2.1 Integration of logic and object-oriented programming..................2 1.2.2 Integration of event-driven and object-oriented programming.............2 1.2.3 Support for component-based programming.......................2 1.2.4 Support for both prototype and class-based systems...................3 1.2.5 Support for multiple object hierarchies..........................3 1.2.6 Separation between interface and implementation....................3 1.2.7 Private, protected and public inheritance.........................3 1.2.8 Private, protected and public object predicates......................3 1.2.9 Parametric objects.....................................3 1.2.10 High level multi-threading programming support....................4 1.2.11 Smooth learning curve...................................4 1.2.12 Compatibility with most Prolog systems and the ISO standard.............4 1.2.13 Performance.........................................4 1.2.14 Logtalk scope........................................4 1.3 Nomenclature............................................5 1.3.1 C++ nomenclature.....................................5 1.3.2 Java nomenclature.....................................6 1.4 Messages...............................................7 1.4.1 Operators used in message sending............................7 1.4.2 Sending a message to an object..............................8 1.4.3 Delegating a message to an object.............................8 1.4.4 Sending a message to self .................................8 1.4.5 Broadcasting........................................8 1.4.6 Calling imported and inherited predicates........................9 1.4.7 Message sending and event generation..........................9 1.5 Objects................................................ 10 1.5.1 Objects, prototypes, classes, and instances........................ 10 1.5.2 Defining a new object.................................... 11 1.5.3 Parametric objects..................................... 13 1.5.4 Finding defined objects................................... 14 1.5.5 Creating a new object in runtime............................. 14 1.5.6 Abolishing an existing object................................ 15 1.5.7 Object directives...................................... 15 1.5.8 Object relationships..................................... 17 1.5.9 Object properties...................................... 18 1.5.10 Built-in objects....................................... 20 1.6 Protocols............................................... 21 i 1.6.1 Defining a new protocol.................................. 21 1.6.2 Finding defined protocols................................. 22 1.6.3 Creating a new protocol in runtime............................ 22 1.6.4 Abolishing an existing protocol.............................. 22 1.6.5 Protocol directives..................................... 23 1.6.6 Protocol relationships.................................... 23 1.6.7 Protocol properties..................................... 24 1.6.8 Implementing protocols.................................. 24 1.6.9 Built-in protocols...................................... 25 1.7 Categories.............................................. 26 1.7.1 Defining a new category.................................. 26 1.7.2 Finding defined categories................................. 28 1.7.3 Creating a new category in runtime............................ 29 1.7.4 Abolishing an existing category.............................. 29 1.7.5 Category directives..................................... 29 1.7.6 Category relationships................................... 30 1.7.7 Category properties..................................... 31 1.7.8 Importing categories.................................... 32 1.7.9 Calling category predicates................................. 33 1.7.10 Parametric categories.................................... 34 1.8 Predicates............................................... 34 1.8.1 Reserved predicate names................................. 34 1.8.2 Declaring predicates.................................... 34 1.8.3 Defining predicates..................................... 42 1.8.4 Built-in object predicates (methods)............................ 47 1.8.5 Predicate properties..................................... 51 1.8.6 Finding declared predicates................................ 52 1.8.7 Calling Prolog predicates.................................. 52 1.9 Inheritance.............................................. 55 1.9.1 Protocol inheritance.................................... 55 1.9.2 Implementation inheritance................................ 55 1.9.3 Public, protected, and private inheritance......................... 58 1.9.4 Composition versus multiple inheritance......................... 59 1.10 Event-driven programming..................................... 60 1.10.1 Definitions.......................................... 60 1.10.2 Event generation...................................... 61 1.10.3 Communicating events to monitors............................ 61 1.10.4 Performance concerns................................... 61 1.10.5 Monitor semantics..................................... 61 1.10.6 Activation order of monitors................................ 62 1.10.7 Event handling....................................... 62 1.11 Multi-threading programming................................... 64 1.11.1 Enabling multi-threading support............................. 64 1.11.2 Enabling objects to make multi-threading calls...................... 64 1.11.3 Multi-threading built-in predicates............................ 65 1.11.4 One-way asynchronous calls................................ 67 1.11.5 Asynchronous calls and synchronized predicates..................... 67 1.11.6 Synchronizing threads through notifications....................... 69 1.11.7 Threaded engines...................................... 69 1.11.8 Multi-threading performance............................... 70 1.12 Error handling............................................ 71 1.12.1 Compiler warnings and errors............................... 71 1.12.2 Runtime errors....................................... 73 1.13 Writing and running applications.................................. 74 ii 1.13.1 Writing applications.................................... 74 1.13.2 Compiling and running applications............................ 76 1.14 Printing messages and asking questions.............................. 84 1.14.1 Printing messages...................................... 85 1.14.2 Message tokenization.................................... 86 1.14.3 Intercepting messages................................... 86 1.14.4 Asking questions...................................... 87 1.14.5 Intercepting questions................................... 88 1.15 Term and goal expansion...................................... 88 1.15.1 Defining expansions.................................... 89 1.15.2 Expanding grammar rules................................. 90 1.15.3 Hook objects........................................ 90 1.15.4 Bypassing expansions.................................... 91 1.15.5 Combining multiple expansions.............................. 91 1.15.6 Using Prolog defined expansions.............................. 91 1.16 Documenting............................................. 91 1.16.1 Documenting directives.................................. 92 1.16.2 Processing and viewing documenting files........................ 94 1.16.3 Inline formatting in comments text............................ 94 1.16.4 Diagrams.......................................... 94 1.17 Debugging.............................................. 95 1.17.1 Compiling source files in debug mode........................... 95 1.17.2 Procedure Box model.................................... 95 1.17.3 Defining spy points..................................... 97 1.17.4 Tracing program execution................................. 98 1.17.5 Debugging using spy points................................ 99 1.17.6 Debugging commands................................... 99 1.17.7 Context-switching calls................................... 100 1.17.8 Using compilation hooks and term expansion for debugging.............. 101 1.17.9 Debugging messages.................................... 101 1.17.10 Ports profiling........................................ 102 1.18 Performance............................................. 102 1.18.1 Local predicate calls.................................... 103 1.18.2 Calls to imported or inherited predicates......................... 103 1.18.3 Calls to module predicates................................. 103 1.18.4 Messages.......................................... 103 1.18.5 Inlining........................................... 103 1.18.6 Generated code simplification and optimizations..................... 103 1.18.7 Other considerations.................................... 104 1.19 Installing Logtalk........................................... 104 1.19.1 Hardware and software requirements........................... 104 1.19.2 Logtalk installers...................................... 105 1.19.3 Source distribution..................................... 105 1.19.4 Distribution overview.................................... 105 1.20 Prolog integration and migration guide.............................. 109 1.20.1 Source files
Recommended publications
  • From Plain Prolog to Logtalk Objects: Effective Code Encapsulation and Reuse
    From Plain Prolog to Logtalk Objects: Effective Code Encapsulation and Reuse Paulo Moura Dep. of Computer Science, Univ. of Beira Interior, Portugal Center for Research in Advanced Computing Systems INESC Porto, Portugal http://logtalk.org/ [email protected] ICLP 2009 Inivited Talk Someone said I need one... 2 Spoilers • Objects in a Prolog world • Logtalk design goals • Logtalk architecture • Logtalk versus Prolog and Prolog modules • Logtalk overview and quick tour • Some demos (if time allows) • Logtalk as a portable Prolog application • Logtalk programming support 3 A warning... • I have a laser and I’m not afraid to use it ... Beware of asking embarrassing questions! • But please feel free to interrupt and ask nice ones that make the speaker shine! 4 A bit of history... • Project started in January 1998 • First version for registered users in July 1998 • First public beta in October 1998 • First stable version in February 1999 5 Logtalk in numbers • Compiler + runtime: ~11000 lines of Prolog code • 37 major releases, 122 including minor ones • Current version: Logtalk 2.37.2 minor release number major release number second generation of Logtalk • ~1500 downloads/month (so many earthlings, so little time) 6 Logtalk distribution • Full sources (compiler/runtime, Prolog config files, libraries) • MacOS X (pkg), Linux (rpm), Debian (deb), and Windows (exe) installers XHTML and PDF User and Reference Manuals • (121 + 144 pages) • +90 programming examples • Support for several text editors and syntax highlighters (text services and code publishing) 7 Objects in Prolog?!? We’re being invaded! 8 Objects have identifiers and dynamic state! • It seems Prolog modules are there first: Identifier! :- module(broadcast, [...]).
    [Show full text]
  • Programming Paradigms & Object-Oriented
    4.3 (Programming Paradigms & Object-Oriented- Computer Science 9608 Programming) with Majid Tahir Syllabus Content: 4.3.1 Programming paradigms Show understanding of what is meant by a programming paradigm Show understanding of the characteristics of a number of programming paradigms (low- level, imperative (procedural), object-oriented, declarative) – low-level programming Demonstrate an ability to write low-level code that uses various address modes: o immediate, direct, indirect, indexed and relative (see Section 1.4.3 and Section 3.6.2) o imperative programming- see details in Section 2.3 (procedural programming) Object-oriented programming (OOP) o demonstrate an ability to solve a problem by designing appropriate classes o demonstrate an ability to write code that demonstrates the use of classes, inheritance, polymorphism and containment (aggregation) declarative programming o demonstrate an ability to solve a problem by writing appropriate facts and rules based on supplied information o demonstrate an ability to write code that can satisfy a goal using facts and rules Programming paradigms 1 4.3 (Programming Paradigms & Object-Oriented- Computer Science 9608 Programming) with Majid Tahir Programming paradigm: A programming paradigm is a set of programming concepts and is a fundamental style of programming. Each paradigm will support a different way of thinking and problem solving. Paradigms are supported by programming language features. Some programming languages support more than one paradigm. There are many different paradigms, not all mutually exclusive. Here are just a few different paradigms. Low-level programming paradigm The features of Low-level programming languages give us the ability to manipulate the contents of memory addresses and registers directly and exploit the architecture of a given processor.
    [Show full text]
  • Knuthweb.Pdf
    Literate Programming Donald E. Knuth Computer Science Department, Stanford University, Stanford, CA 94305, USA The author and his associates have been experimenting for the past several years with a program- ming language and documentation system called WEB. This paper presents WEB by example, and discusses why the new system appears to be an improvement over previous ones. I would ordinarily have assigned to student research A. INTRODUCTION assistants; and why? Because it seems to me that at last I’m able to write programs as they should be written. The past ten years have witnessed substantial improve- My programs are not only explained better than ever ments in programming methodology. This advance, before; they also are better programs, because the new carried out under the banner of “structured program- methodology encourages me to do a better job. For ming,” has led to programs that are more reliable and these reasons I am compelled to write this paper, in easier to comprehend; yet the results are not entirely hopes that my experiences will prove to be relevant to satisfactory. My purpose in the present paper is to others. propose another motto that may be appropriate for the I must confess that there may also be a bit of mal- next decade, as we attempt to make further progress ice in my choice of a title. During the 1970s I was in the state of the art. I believe that the time is ripe coerced like everybody else into adopting the ideas of for significantly better documentation of programs, and structured programming, because I couldn’t bear to be that we can best achieve this by considering programs found guilty of writing unstructured programs.
    [Show full text]
  • Programming Pearls: a Literate Program
    by jot1 Be~~tley programming with Special Guest Oysters Don Knuth and Doug McIlroy pearls A LITERATE PROGRAM Last month‘s column introduced Don Knuth’s style of frequency; or there might not even be as many as k “Literate Programming” and his WEB system for building words. Let’s be more precise: The most common programs that are works of literature. This column pre- words are to be printed in order of decreasing fre- sents a literate program by Knuth (its origins are sketched quency, with words of equal frequency listed in al- in last month‘s column) and, as befits literature, a review. phabetic order. Printing should stop after k words So without further ado, here is Knuth’s program, have been output, if more than k words are present. retypeset in Communications style. -Jon Bentley 2. The input file is assumed to contain the given Common Words Section text. If it begins with a positive decimal number Introduction.. , . , , . , . , . , , . 1 (preceded by optional blanks), that number will be Strategic considerations . , a the value of k; otherwise we shall assume that Basic input routines . , , . 9 k = 100. Answers will be sent to the output file. Dictionary lookup . , . , . , .17 define default-k = 100 (use this value if k isn’t The frequency counts . .32 otherwise specified) Sortingatrie . ...36 Theendgame................................41 3. Besides solving the given problem, this program is Index . ...42 supposed to be an example of the WEB system, for people who know some Pascal but who have never 1. Introduction. The purpose of this program is to seen WEB before.
    [Show full text]
  • Functional and Imperative Object-Oriented Programming in Theory and Practice
    Uppsala universitet Inst. för informatik och media Functional and Imperative Object-Oriented Programming in Theory and Practice A Study of Online Discussions in the Programming Community Per Jernlund & Martin Stenberg Kurs: Examensarbete Nivå: C Termin: VT-19 Datum: 14-06-2019 Abstract Functional programming (FP) has progressively become more prevalent and techniques from the FP paradigm has been implemented in many different Imperative object-oriented programming (OOP) languages. However, there is no indication that OOP is going out of style. Nevertheless the increased popularity in FP has sparked new discussions across the Internet between the FP and OOP communities regarding a multitude of related aspects. These discussions could provide insights into the questions and challenges faced by programmers today. This thesis investigates these online discussions in a small and contemporary scale in order to identify the most discussed aspect of FP and OOP. Once identified the statements and claims made by various discussion participants were selected and compared to literature relating to the aspects and the theory behind the paradigms in order to determine whether there was any discrepancies between practitioners and theory. It was done in order to investigate whether the practitioners had different ideas in the form of best practices that could influence theories. The most discussed aspect within FP and OOP was immutability and state relating primarily to the aspects of concurrency and performance. ​ ​ ​ ​ ​ ​ This thesis presents a selection of representative quotes that illustrate the different points of view held by groups in the community and then addresses those claims by investigating what is said in literature.
    [Show full text]
  • 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]
  • Teaching Foundations of Computation and Deduction Through Literate Functional Programming and Type Theory Formalization
    Teaching Foundations of Computation and Deduction Through Literate Functional Programming and Type Theory Formalization Gérard Huet Inria Paris Laboratory, France Abstract We describe experiments in teaching fundamental informatics notions around mathematical struc- tures for formal concepts, and effective algorithms to manipulate them. The major themes of lambda-calculus and type theory served as guides for the effective implementation of functional programming languages and higher-order proof assistants, appropriate for reflecting the theor- etical material into effective tools to represent constructively the concepts and formally certify the proofs of their properties. Progressively, a literate programming and proving style replaced informal mathematics in the presentation of the material as executable course notes. The talk will evoke the various stages of (in)completion of the corresponding set of notes along the years (see [1, 2, 14, 5, 6, 10, 12, 16, 7, 15, 17, 9, 3, 13, 11, 4, 8]), and tell how their elaboration proved to be essential to the discovery of fundamental results. 1998 ACM Subject Classification F.3.1 Specifying and Verifying Programs, F.4.1 Mathematical Logic and G.4 Mathematical Software Keywords and phrases Foundations, Computation, Deduction, Programming, Proofs Digital Object Identifier 10.4230/LIPIcs.FSCD.2016.3 Category Invited Talk References 1 Gérard Huet. Initiation à la logique mathématique. Notes de cours du DEA d’Informatique, Université Paris-Sud, 1977. 2 Gérard Huet. Démonstration automatique en logique de premier ordre et programmation en clauses de horn. Notes de cours du DEA d’Informatique, Université Paris-Sud, 1978. 3 Gérard Huet. Confluent reductions: Abstract properties and applications to term rewriting systems.
    [Show full text]
  • Intercepting Functions for Memoization Arjun Suresh
    Intercepting Functions for Memoization Arjun Suresh To cite this version: Arjun Suresh. Intercepting Functions for Memoization. Other [cs.OH]. Université de Rennes 1, 2016. English. tel-01410539v1 HAL Id: tel-01410539 https://hal.inria.fr/tel-01410539v1 Submitted on 6 Dec 2016 (v1), last revised 11 May 2017 (v2) HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. ANNEE´ 2016 THESE` / UNIVERSITE´ DE RENNES 1 sous le sceau de l’Universite´ Bretagne Loire En Cotutelle Internationale avec pour le grade de DOCTEUR DE L’UNIVERSITE´ DE RENNES 1 Mention : Informatique Ecole´ doctorale Matisse present´ ee´ par Arjun SURESH prepar´ ee´ a` l’unite´ de recherche INRIA Institut National de Recherche en Informatique et Automatique Universite´ de Rennes 1 These` soutenue a` Rennes Intercepting le 10 Mai, 2016 devant le jury compose´ de : Functions Fabrice RASTELLO Charge´ de recherche Inria / Rapporteur Jean-Michel MULLER for Directeur de recherche CNRS / Rapporteur Sandrine BLAZY Memoization Professeur a` l’Universite´ de Rennes 1 / Examinateur Vincent LOECHNER Maˆıtre de conferences,´ Universite´ Louis Pasteur, Stras- bourg / Examinateur Erven ROHOU Directeur de recherche INRIA / Directeur de these` Andre´ SEZNEC Directeur de recherche INRIA / Co-directeur de these` If you save now you might benefit later.
    [Show full text]
  • Programming Language
    Programming language A programming language is a formal language, which comprises a set of instructions that produce various kinds of output. Programming languages are used in computer programming to implement algorithms. Most programming languages consist of instructions for computers. There are programmable machines that use a set of specific instructions, rather than general programming languages. Early ones preceded the invention of the digital computer, the first probably being the automatic flute player described in the 9th century by the brothers Musa in Baghdad, during the Islamic Golden Age.[1] Since the early 1800s, programs have been used to direct the behavior of machines such as Jacquard looms, music boxes and player pianos.[2] The programs for these The source code for a simple computer program written in theC machines (such as a player piano's scrolls) did not programming language. When compiled and run, it will give the output "Hello, world!". produce different behavior in response to different inputs or conditions. Thousands of different programming languages have been created, and more are being created every year. Many programming languages are written in an imperative form (i.e., as a sequence of operations to perform) while other languages use the declarative form (i.e. the desired result is specified, not how to achieve it). The description of a programming language is usually split into the two components ofsyntax (form) and semantics (meaning). Some languages are defined by a specification document (for example, theC programming language is specified by an ISO Standard) while other languages (such as Perl) have a dominant implementation that is treated as a reference.
    [Show full text]
  • Logic Programming Logic Department of Informatics Informatics of Department Based on INF 3110 – 2016 2
    Logic Programming INF 3110 3110 INF Volker Stolz – 2016 [email protected] Department of Informatics – University of Oslo Based on slides by G. Schneider, A. Torjusen and Martin Giese, UiO. 1 Outline ◆ A bit of history ◆ Brief overview of the logical paradigm 3110 INF – ◆ Facts, rules, queries and unification 2016 ◆ Lists in Prolog ◆ Different views of a Prolog program 2 History of Logic Programming ◆ Origin in automated theorem proving ◆ Based on the syntax of first-order logic ◆ 1930s: “Computation as deduction” paradigm – K. Gödel 3110 INF & J. Herbrand – ◆ 1965: “A Machine-Oriented Logic Based on the Resolution 2016 Principle” – Robinson: Resolution, unification and a unification algorithm. • Possible to prove theorems of first-order logic ◆ Early seventies: Logic programs with a restricted form of resolution introduced by R. Kowalski • The proof process results in a satisfying substitution. • Certain logical formulas can be interpreted as programs 3 History of Logic Programming (cont.) ◆ Programming languages for natural language processing - A. Colmerauer & colleagues ◆ 1971–1973: Prolog - Kowalski and Colmerauer teams 3110 INF working together ◆ First implementation in Algol-W – Philippe Roussel – 2016 ◆ 1983: WAM, Warren Abstract Machine ◆ Influences of the paradigm: • Deductive databases (70’s) • Japanese Fifth Generation Project (1982-1991) • Constraint Logic Programming • Parts of Semantic Web reasoning • Inductive Logic Programming (machine learning) 4 Paradigms: Overview ◆ Procedural/imperative Programming • A program execution is regarded as a sequence of operations manipulating a set of registers (programmable calculator) 3110 INF ◆ Functional Programming • A program is regarded as a mathematical function – 2016 ◆ Object-Oriented Programming • A program execution is regarded as a physical model simulating a real or imaginary part of the world ◆ Constraint-Oriented/Declarative (Logic) Programming • A program is regarded as a set of equations ◆ Aspect-Oriented, Intensional, ..
    [Show full text]
  • Multi-Paradigm Declarative Languages*
    c Springer-Verlag In Proc. of the International Conference on Logic Programming, ICLP 2007. Springer LNCS 4670, pp. 45-75, 2007 Multi-paradigm Declarative Languages⋆ Michael Hanus Institut f¨ur Informatik, CAU Kiel, D-24098 Kiel, Germany. [email protected] Abstract. Declarative programming languages advocate a program- ming style expressing the properties of problems and their solutions rather than how to compute individual solutions. Depending on the un- derlying formalism to express such properties, one can distinguish differ- ent classes of declarative languages, like functional, logic, or constraint programming languages. This paper surveys approaches to combine these different classes into a single programming language. 1 Introduction Compared to traditional imperative languages, declarative programming lan- guages provide a higher and more abstract level of programming that leads to reliable and maintainable programs. This is mainly due to the fact that, in con- trast to imperative programming, one does not describe how to obtain a solution to a problem by performing a sequence of steps but what are the properties of the problem and the expected solutions. In order to define a concrete declarative language, one has to fix a base formalism that has a clear mathematical founda- tion as well as a reasonable execution model (since we consider a programming language rather than a specification language). Depending on such formalisms, the following important classes of declarative languages can be distinguished: – Functional languages: They are based on the lambda calculus and term rewriting. Programs consist of functions defined by equations that are used from left to right to evaluate expressions.
    [Show full text]
  • Typeset MMIX Programs with TEX Udo Wermuth Abstract a TEX Macro
    TUGboat, Volume 35 (2014), No. 3 297 Typeset MMIX programs with TEX Example: In section 9 the lines \See also sec- tion 10." and \This code is used in section 24." are given. Udo Wermuth No such line appears in section 10 as it only ex- tends the replacement code of section 9. (Note that Abstract section 10 has in its headline the number 9.) In section 24 the reference to section 9 stands for all of ATEX macro package is presented as a literate pro- the eight code lines stated in sections 9 and 10. gram. It can be included in programs written in the If a section is not used in any other section then languages MMIX or MMIXAL without affecting the it is a root and during the extraction of the code a assembler. Such an instrumented file can be pro- file is created that has the name of the root. This file cessed by TEX to get nicely formatted output. Only collects all the code in the sequence of the referenced a new first line and a new last line must be entered. sections from the code part. The collection process And for each end-of-line comment a flag is set to for all root sections is called tangle. A second pro- indicate that the comment is written in TEX. cess is called weave. It outputs the documentation and the code parts as a TEX document. How to read the following program Example: The following program has only one The text that starts in the next chapter is a literate root that is defined in section 4 with the headline program [2, 1] written in a style similar to noweb [7].
    [Show full text]