Automating Iterative Tasks with Programming by Demonstration

Total Page:16

File Type:pdf, Size:1020Kb

Automating Iterative Tasks with Programming by Demonstration http://waikato.researchgateway.ac.nz/ Research Commons at the University of Waikato Copyright Statement: The digital copy of this thesis is protected by the Copyright Act 1994 (New Zealand). The thesis may be consulted by you, provided you comply with the provisions of the Act and the following conditions of use: Any use you make of these documents or images must be for research or private study purposes only, and you may not make them available to any other person. Authors control the copyright of their thesis. You will recognise the author’s right to be identified as the author of the thesis, and due acknowledgement will be made to the author where appropriate. You will obtain the author’s permission before publishing any material from the thesis. Department of Computer Science Hamilton, New Zealand Automating iterative tasks with programming by demonstration Gordon W. Paynter This thesis is submitted in partial fulfilment of the requirements for the degree of Doctor of Philosophy at The University of Waikato. February 26, 2000 © 2000 Gordon W. Paynter Abstract iii Abstract Programming by demonstration is an end-user programming technique that allows people to create programs by showing the computer examples of what they want to do. Users do not need specialised programming skills. Instead, they instruct the computer by demonstrating examples, much as they might show another person how to do the task. Programming by demonstration empowers users to create programs that perform tedious and time-consuming computer chores. However, it is not in widespread use, and is instead confined to research applications that end users never see. This makes it difficult to evaluate programming by demonstration tools and techniques. This thesis claims that domain-independent programming by demonstration can be made available in existing applications and used to automate iterative tasks by end users. It is supported by Familiar, a domain-independent, AppleScript-based programming-by-demonstration tool embodying standard machine learning algorithms. Familiar is designed for end users, so works in the existing applications that they regularly use. The assertion that programming by demonstration can be made available in existing applications is validated by identifying the relevant platform requirements and a range of platforms that meet them. A detailed scrutiny of AppleScript highlights problems with the architecture and with many implementations, and yields a set of guidelines for designing applications that support programming-by-demonstration systems and other agents. An evaluation shows that end users are capable of using programming by demonstration to automate iterative tasks. However, the subjects tended to prefer other tools, choosing Familiar only when the alternatives were unsuitable or unavailable. Familiar’s inferencing is evaluated on an extensive set of examples, highlighting the tasks it can perform and the functionality it requires. Acknowledgments v Acknowledgments I sometimes wonder what I would be doing now if Ian Witten had not talked me into writing a thesis. (I imagine I would have cashed in my stock options and retired by now.) I also wonder what might have become of me had I attempted a thesis under a supervisor less generous with his time and experience than Ian, without whose encouragement and example I surely would never have finished. Thanks Ian. My two other supervisors, Geoff Holmes and Mark Apperley, have been very supportive, and patient. I’d like to thank them, and those others who have read this thesis and offered advice: Sally Jo Cunningham, Steve Jones, Simon Christiansen, Stuart Yeates, and Grant Floyd; and also my mother (who made one helpful suggestion before falling asleep at Section 1.3). I’m grateful to the many people who have commented on, and contributed to, my research over the last four years, including Allen Cypher, Eibe Frank, Craig Nevill-Manning, Carl Gutwin, Henry Lieberman, the staff of my department, and numerous others. I have borrowed code and ideas from any number of people, including Tom Bonura, Roman Zeiliger, Marty Geier (and his colleagues at Mitre), and the Weka programmers. I am sure I have omitted numerous others; for this I apologise. I would surely not have lasted four years without the diversions afforded me by my flatmates: Simon, Sarah, Dale, Teri, Donna, Cat, Nick, Jan, Elliot, and others too numerous to mention. Our department is blessed with a fantastic soccer team, comprising many of our students and staff. Thanks Alvin (who started it all), Annette, Aziz, Carl, Chithiran, Conrad, David B., David M., Dong, Eibe, Geoff, Jamie, Len, Max, Kim, Richard, Rob, Steve, Stuart, Talia, Tony, Yong… Finally, I’d like to thank my parents, my brother Craig, my sister Sharon, and the rest of my family, particularly the Gordons, for their support and encouragement. I dedicate this thesis, and the years of work it represents, to my uncle Doug Gordon, without whose support it could never have been attempted, let alone finished. Table of contents vii Table of contents Abstract iii Acknowledgements v List of Figures xv List of Tables xix Chapter 1 Introduction 1 1.1 Programming by demonstration (PBD) ...............................................1 1.2 Thesis statement.......................................................................................3 1.2.1 Automating iterative tasks...................................................4 1.2.2 End users and applications ..................................................5 1.2.3 Domain independence..........................................................5 1.3 Examples of iterative tasks.....................................................................6 1.3.1 Image transfer and conversion ............................................7 1.3.2 Averaging column data ........................................................8 1.3.3 Indexing document files .......................................................9 1.4 Thesis structure......................................................................................10 viii Table of contents Chapter 2 Background 13 2.1 Definitions and usage........................................................................... 14 2.2 Automating iteration............................................................................ 21 2.3 PBD and iteration problems ................................................................ 24 2.4 PBD and repetition problems.............................................................. 27 2.4.1 Macro recorders .................................................................. 28 2.4.2 Extending macro recorders ............................................... 28 2.4.3 Editable histories................................................................. 30 2.5 Other demonstrational interfaces....................................................... 31 2.6 Discussion and criticism of PBD......................................................... 34 2.6.1 Problems with agents ......................................................... 34 2.6.2 Problems with PBD............................................................. 35 2.6.3 Challenges for PBD research............................................. 37 2.7 Summary ................................................................................................ 38 Chapter 3 Design considerations 39 3.1 Existing PBD designs............................................................................ 40 3.1.1 Feature-oriented designs ................................................... 41 3.1.2 User-oriented designs......................................................... 41 3.1.3 Successful end-user programming................................... 43 3.2 PBD for the end user............................................................................. 44 3.2.1 End user motivations.......................................................... 44 3.2.2 End user abilities................................................................. 45 3.2.3 End user attitudes ............................................................... 45 3.2.4 Design guidelines................................................................ 47 3.3 The Familiar user interface.................................................................. 51 3.3.1 Arranging files..................................................................... 52 3.3.2 Arranging files when Familiar makes an error .............. 54 3.3.3 Sorting files .......................................................................... 56 3.3.4 Converting images.............................................................. 59 3.3.5 Converting images with the evaluation interface .......... 61 3.4 Familiar’s limitations............................................................................ 63 3.5 Summary ................................................................................................ 64 Table of contents ix Chapter 4 The Familiar architecture 65 4.1 System overview....................................................................................67 4.2 The event recorder.................................................................................70 4.2.1 AppleScript...........................................................................70 4.2.2 Application knowledge ......................................................71 4.2.3 Background knowledge......................................................76 Application independence ..............................................................77
Recommended publications
  • How Lisp Systems Look Different in Proceedings of European Conference on Software Maintenance and Reengineering (CSMR 2008)
    How Lisp Systems Look Different In Proceedings of European Conference on Software Maintenance and Reengineering (CSMR 2008) Adrian Dozsa Tudor Gˆırba Radu Marinescu Politehnica University of Timis¸oara University of Berne Politehnica University of Timis¸oara Romania Switzerland Romania [email protected] [email protected] [email protected] Abstract rently used in a variety of domains, like bio-informatics (BioBike), data mining (PEPITe), knowledge-based en- Many reverse engineering approaches have been devel- gineering (Cycorp or Genworks), video games (Naughty oped to analyze software systems written in different lan- Dog), flight scheduling (ITA Software), natural language guages like C/C++ or Java. These approaches typically processing (SRI International), CAD (ICAD or OneSpace), rely on a meta-model, that is either specific for the language financial applications (American Express), web program- at hand or language independent (e.g. UML). However, one ming (Yahoo! Store or reddit.com), telecom (AT&T, British language that was hardly addressed is Lisp. While at first Telecom Labs or France Telecom R&D), electronic design sight it can be accommodated by current language inde- automation (AMD or American Microsystems) or planning pendent meta-models, Lisp has some unique features (e.g. systems (NASA’s Mars Pathfinder spacecraft mission) [16]. macros, CLOS entities) that are crucial for reverse engi- neering Lisp systems. In this paper we propose a suite of Why Lisp is Different. In spite of its almost fifty-year new visualizations that reveal the special traits of the Lisp history, and of the fact that other programming languages language and thus help in understanding complex Lisp sys- borrowed concepts from it, Lisp still presents some unique tems.
    [Show full text]
  • Lisp Tutorial
    Gene Kim 9/9/2016 CSC 2/444 Lisp Tutorial About this Document This document was written to accompany an in-person Lisp tutorial. Therefore, the information on this document alone is not likely to be sufficient to get a good understanding of Lisp. However, the functions and operators that are listed here are a good starting point, so you may look up specifications and examples of usage for those functions in the Common Lisp HyperSpec (CLHS) to get an understanding of their usage. Getting Started Note on Common Lisp Implementations I will use Allegro Common Lisp since it is what is used by Len (and my research). However, for the purposes of this class we won’t be using many (if any) features that are specific to common lisp implementations so you may use any of the common lisp implementations available in the URCS servers. If you are using any libraries that are implementation-specific for assignments in this class, I would strongly urge you to rethink your approach if possible. If we (the TAs) deem any of these features to be solving to much of the assigned problem, you will not receive full credit for the assignment. To see if a function is in the Common Lisp specifications see the Common Lisp HyperSpec (CLHS). Simply google the function followed by “clhs” to see if an entry shows up. Available Common Lisp implementations (as far as I know): - Allegro Common Lisp (acl or alisp will start an Allegro REPL) - CMU Common Lisp (cmucl or lisp will start a CMUCL REPL) - Steel Bank Common Lisp (sbcl will start an SBCL REPL) IDE/Editor It is not important for this class to have an extensive IDE since we will be working on small coding projects.
    [Show full text]
  • Common Lisp - Viel Mehr Als Nur D¨Amliche Klammern
    Einf¨uhrung Geschichtliches Die Programmiersprache Abschluß Common Lisp - viel mehr als nur d¨amliche Klammern Alexander Schreiber <[email protected]> http://www.thangorodrim.de Chemnitzer Linux-Tage 2005 Greenspun’s Tenth Rule of Programming: “Any sufficiently-complicated C or Fortran program contains an ad-hoc, informally-specified bug-ridden slow implementation of half of Common Lisp.” Alexander Schreiber <[email protected]> Common Lisp - viel mehr als nur d¨amliche Klammern 1 / 30 Einf¨uhrung Geschichtliches Die Programmiersprache Abschluß Ubersicht¨ 1 Einf¨uhrung 2 Geschichtliches 3 Die Programmiersprache 4 Abschluß Alexander Schreiber <[email protected]> Common Lisp - viel mehr als nur d¨amliche Klammern 2 / 30 Einf¨uhrung Geschichtliches Die Programmiersprache Abschluß Lisp? Wof¨ur? NASA: Remote Agent (Deep Space 1), Planner (Mars Pathfinder), Viaweb, gekauft von Yahoo f¨ur50 Millionen $, ITA Software: Orbitz engine (Flugticket Planung), Square USA: Production tracking f¨ur“Final Fantasy”, Naughty Dog Software: Crash Bandicoot auf Sony Playstation, AMD & AMI: Chip-Design & Verifizierung, typischerweise komplexe Probleme: Wissensverarbeitung, Expertensysteme, Planungssysteme Alexander Schreiber <[email protected]> Common Lisp - viel mehr als nur d¨amliche Klammern 3 / 30 Einf¨uhrung Geschichtliches Die Programmiersprache Abschluß Lisp? Wof¨ur? NASA: Remote Agent (Deep Space 1), Planner (Mars Pathfinder), Viaweb, gekauft von Yahoo f¨ur50 Millionen $, ITA Software: Orbitz engine (Flugticket Planung), Square USA: Production tracking
    [Show full text]
  • Advanced Use of Lisp's FORMAT Function
    Advanced Use of Lisp’s FORMAT Function Gene Michael Stover created 22 January 2004 updated Saturday, 30 October 2004 Copyright c 2004 Gene Michael Stover. All rights reserved. Permission to copy, store, & view this document unmodified & in its entirety is granted. Contents 1 Introduction 1 2 Wanted & To Do 2 3 How to Print a Row 2 4 How to Print a Table 3 5 How to Use Format for Word Wrap 4 6 How to Print a Comma-Separated List 6 7 HowtoUseCommasinEnglishStyle 7 8 Conclusion 7 A Change Log 8 B Other File Formats 8 1 Introduction Lisp’s format function is analogous to C’s printf function, but format can do a whole lot more. format can iterate, use conditionals, process nested format strings, & recurse into format strings embedded into its arguments. The more-or-less official documentation for format is at the Common Lisp Hyperspec[X3J]. There is a complete if terse description of it in Paul Graham’s ANSI Common Lisp[Gra96], but my favorite description of format is in Franz’s Common Lisp The Reference[Inc88]. 1 Knowing the details of how something works isn’t the same as knowing how to use it well. Good applications of format aren’t obvious from its documentation. Thus this article. 2 Wanted & To Do Read the original article about format[Wat89]. Possibly incorporate ideas from it, or refer to them. Definitely refer to it in this article so people know it exists. (I didn’t know it existed at all even though I searched the web for such articles before I wrote this one.
    [Show full text]
  • Memory Pool System Documentation Release 1.111.0
    Memory Pool System Documentation Release 1.111.0 Ravenbrook Limited May 23, 2013 CONTENTS i ii CHAPTER ONE GUIDE 1.1 Overview of the Memory Pool System The Memory Pool System is a very general, adaptable, flexible, reliable, and efficient memory management system. It permits the flexible combination of memory management techniques, supporting manual and automatic memory management, inline allocation, finalization, weakness, and multiple concurrent co-operating incremental generational garbage collections. It also includes a library of memory pool classes implementing specialized memory management policies. The MPS has been in development since 1994 and deployed in successful commercial products since 1997. Bugs are almost unknown in production. It is under continuous development and support by Ravenbrook. The MPS is distributed under an open source license. The license is designed to make it possible for you to use the MPS in your own projects, provided that you either don’t distribute your product, or your product is open source too. If the licensing terms aren’t suitable for you (for example, you’re developing a closed-source commercial product or a compiler run-time system) you can easily license the MPS under different terms from Ravenbrook by arrangement. Please contact us at [email protected] for details. 1.1.1 Supported target platforms The MPS is currently supported for deployment on: • Windows XP or later on IA-32 and x86-64, using Microsoft Visual C/C++; • Linux (Ubuntu 11 and RHEL 6.3 known good, otherwise YMMV) on IA-32 and x86-64, using GCC; • FreeBSD 7 or later, on IA-32 and x86-64, using GCC; • OS X 10.4 or later, on IA-32 and x86-64 (single threaded only), using Clang/LLVM.
    [Show full text]
  • Objektové Programování Poznámky K Přednášce
    Objektové programování Poznámky k přednášce Michal Krupka 18. prosince 2016 1 Obsah 1 Od Scheme k Lispu 7 1.1 Základní rozdíly mezi Schemem a Common Lispem . 8 1.2 Common Lisp: základní výbava . 14 2 Objekty a třídy 37 2.1 Základní pojmy ........................... 37 2.2 Třídy a instance v Common Lispu . 40 2.3 Inicializace slotů nových instancí . 49 ÚLOHY ................................... 52 3 Zapouzdření a polymorfismus 55 3.1 Princip zapouzdření ........................ 55 3.2 Úprava tříd point a circle ................... 61 3.3 Třída picture ........................... 64 3.4 Vlastnosti ............................... 67 3.5 Kreslení pomocí knihovny micro-graphics . 68 3.6 Kreslení grafických objektů .................... 72 3.7 Princip polymorfismu ....................... 81 3.8 Polygony ............................... 83 3.9 Geometrické transformace ..................... 87 ÚLOHY ................................... 89 4 Dědičnost 91 4.1 Princip dědičnosti a pravidlo is-a . 91 4.2 Určení předka v definici třídy ................... 98 4.3 Poznámka o běžných jazycích . 102 4.4 Přepisování metod . 102 4.5 Volání zděděné metody . 104 4.6 Inicializace instancí . 110 3 4 OBSAH 4.7 Návrh stromu dědičnosti . 111 ÚLOHY ................................... 112 5 Zpětná volání 115 5.1 Zpětná volání v knihovně micro-graphics . 115 5.2 Překreslování oken po vnější změně . 117 5.3 Překreslení při změně okna . 118 5.4 Překreslování při změnách objektů . 120 ÚLOHY ................................... 124 6 Klikání a jiné události 127 6.1 Jednoduché obsloužení vstupu z myši . 127 6.2 Zpravení grafického objektu o kliknutí . 129 6.3 Princip vlastnění, delegování, události . 133 6.4 Události ev-changing a ev-change . 136 6.5 Reakce na kliknutí: událost ev-mouse-down . 140 ÚLOHY ..................................
    [Show full text]
  • Successful Lisp - Contents
    Successful Lisp - Contents Table of Contents ● About the Author ● About the Book ● Dedication ● Credits ● Copyright ● Acknowledgments ● Foreword ● Introduction 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 Appendix A ● Chapter 1 - Why Bother? Or: Objections Answered Chapter objective: Describe the most common objections to Lisp, and answer each with advice on state-of-the-art implementations and previews of what this book will explain. ❍ I looked at Lisp before, and didn't understand it. ❍ I can't see the program for the parentheses. ❍ Lisp is very slow compared to my favorite language. ❍ No one else writes programs in Lisp. ❍ Lisp doesn't let me use graphical interfaces. ❍ I can't call other people's code from Lisp. ❍ Lisp's garbage collector causes unpredictable pauses when my program runs. ❍ Lisp is a huge language. ❍ Lisp is only for artificial intelligence research. ❍ Lisp doesn't have any good programming tools. ❍ Lisp uses too much memory. ❍ Lisp uses too much disk space. ❍ I can't find a good Lisp compiler. ● Chapter 2 - Is this Book for Me? Chapter objective: Describe how this book will benefit the reader, with specific examples and references to chapter contents. ❍ The Professional Programmer http://psg.com/~dlamkins/sl/contents.html (1 of 13)11/3/2006 5:46:04 PM Successful Lisp - Contents ❍ The Student ❍ The Hobbyist ❍ The Former Lisp Acquaintance ❍ The Curious ● Chapter 3 - Essential Lisp in Twelve Lessons Chapter objective: Explain Lisp in its simplest form, without worrying about the special cases that can confuse beginners.
    [Show full text]
  • Jon L. White Collection on Common Lisp
    http://oac.cdlib.org/findaid/ark:/13030/c89w0mkb No online items Jon L. White collection on Common Lisp Finding aid prepared by Bo Doub, Kim Hayden, and Sara Chabino Lott Processing of this collection was made possible through generous funding from The Andrew W. Mellon Foundation, administered through the Council on Library and Information Resources' Cataloging Hidden Special Collections and Archives grant. Computer History Museum 1401 N. Shoreline Blvd. Mountain View, CA, 94043 (650) 810-1010 [email protected] March 2017 Jon L. White collection on X6823.2013 1 Common Lisp Title: Jon L. White collection Identifier/Call Number: X6823.2013 Contributing Institution: Computer History Museum Language of Material: English Physical Description: 8.75 Linear feet,7 record cartons Date (bulk): Bulk, 1978-1995 Date (inclusive): 1963-2012 Abstract: The Jon L. White collection on Common Lisp contains material relating to the development and standardization of the programming language Common Lisp and, more generally, the Lisp family of programming languages. Records date from 1963 to 2012, with the bulk of the material ranging from 1978 to 1995, when White was working at MIT’s Artificial Intelligence Laboratory, Xerox PARC (Palo Alto Research Center), Lucid, and Harlequin Group. Throughout many of these positions, White was serving on the X3J13 Committee to formalize a Common Lisp standard, which aimed to combine and standardize many previous dialects of Lisp. This collection consists of conference proceedings, manuals, X3J13 Committee correspondence and meeting minutes, notebooks, technical papers, and periodicals documenting White’s work in all of these roles. Other dialects of Lisp--especially MAClisp--are also major focuses of the collection.
    [Show full text]
  • Basic Lisp Techniques
    Basic Lisp Techniques David J. Cooper, Jr. February 14, 2011 ii 0Copyright c 2011, Franz Inc. and David J. Cooper, Jr. Foreword1 Computers, and the software applications that power them, permeate every facet of our daily lives. From groceries to airline reservations to dental appointments, our reliance on technology is all-encompassing. And, it’s not enough. Every day, our expectations of technology and software increase: • smart appliances that can be controlled via the internet • better search engines that generate information we actually want • voice-activated laptops • cars that know exactly where to go The list is endless. Unfortunately, there is not an endless supply of programmers and developers to satisfy our insatiable appetites for new features and gadgets. Every day, hundreds of magazine and on-line articles focus on the time and people resources needed to support future technological expectations. Further, the days of unlimited funding are over. Investors want to see results, fast. Common Lisp (CL) is one of the few languages and development options that can meet these challenges. Powerful, flexible, changeable on the fly — increasingly, CL is playing a leading role in areas with complex problem-solving demands. Engineers in the fields of bioinformatics, scheduling, data mining, document management, B2B, and E-commerce have all turned to CL to complete their applications on time and within budget. CL, however, no longer just appropriate for the most complex problems. Applications of modest complexity, but with demanding needs for fast development cycles and customization, are also ideal candidates for CL. Other languages have tried to mimic CL, with limited success.
    [Show full text]
  • Clarification Proposal for CLHS Section 22.3 Version 1.1
    Clarification Proposal for CLHS Section 22.3 Version 1.1 Didier Verna <[email protected]> Copyright c 2011 Didier Verna Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided also that the section entitled \Copy- ing" is included exactly as in the original. Permission is granted to copy and distribute translations of this manual into an- other language, under the above conditions for modified versions, except that this permission notice may be translated as well. Copying 1 Copying This work may be distributed and/or modified under the conditions of the LaTeX Project Public License, either version 1.3 of this license or (at your option) any later version. The latest version of this license is in http://www.latex-project.org/lppl.txt and version 1.3 or later is part of all distributions of LaTeX version 2005/12/01 or later. This work has the LPPL maintenance status `maintained'. The Current Maintainer of this work is Didier Verna. Chapter 1: Motivation 2 1 Motivation Section 22.3 \Formatted Output" of the Common Lisp Hyperspec describes the syntax and semantics of format directives. We believe that the standard is underspecified in two related areas. 1.1 Trailing Commas The standard describes the syntax of directive parameters as follows. A directive consists of a tilde, optional prefix parameters separated by commas, [...]. ¨ It also gives the following example.
    [Show full text]
  • The Complete Idiot's Guide to Common Lisp Packages1
    The Complete Idiot’s Guide to Common Lisp Packages1 Erann Gat Copyright © 2003 by the author. Permission is hereby granted for non-commercial use provided this notice is retained. 1. Introduction When coding a large project with multiple programmers two different programmers will often want to use the same name for two different purposes. It is possible to solve this problem using a naming convention, e.g. Bob prefixes all his names with “BOB-“ and Jane prefixes all her names with “JANE-“. This is in fact how Scheme addresses this problem (or fails to address it as the case may be). Common Lisp provides a language mechanism called packages for segregating namespaces. Here’s an example of how packages work: ? (make-package :bob) #<Package "BOB"> ? (make-package :jane) #<Package "JANE"> ? (in-package bob) #<Package "BOB"> ? (defun foo () "This is Bob's foo") FOO ? (in-package jane) #<Package "JANE"> ? (defun foo () "This is Jane's foo") FOO ? (foo) "This is Jane's foo" ? (in-package bob) #<Package "BOB"> ? (foo) "This is Bob's foo" ? (NOTE: Code examples are cut-and-pasted from Macintosh Common Lisp (MCL). The command prompt in MCL is a question mark.) Bob and Jane each have a function named FOO that does something different, and they don’t conflict with each other. 1 Version 1.2 What if Bob wants to use a function written by Jane? There are several ways he can do it. One is to use a special syntax to indicate that a different package is to be used: ? (in-package bob) #<Package "BOB"> ? (jane::foo) "This is Jane's foo" ? Another is to import what he wants to use into his own package.
    [Show full text]
  • Common Lisp Reference Manual the Common Lisp Reference Manual Copyright C 2006 Robert Strandh
    Common Lisp Reference Manual The Common Lisp Reference Manual Copyright c 2006 Robert Strandh. i Table of Contents 1 Introduction............................... 1 2 Terminology and conventions ............... 2 2.1 Introduction ................................................ 2 2.2 General..................................................... 2 3 Numbers .................................. 3 3.1 Introduction ................................................ 3 4 Cons cells ................................. 4 5 Sequences ................................. 5 5.1 Introduction ................................................ 5 5.2 Lists ....................................................... 5 5.2.1 Standard functions, macros, and special operators on lists.. 5 5.3 Vectors ..................................................... 5 6 Structures ................................. 6 7 Generalized references ..................... 7 8 Standard functions, macros, and special operators................................. 8 car ........................................................ 8 cdr ........................................................ 8 9 Standard types and classes ................. 9 Index ....................................... 10 Chapter 1: Introduction 1 1 Introduction You are reading the Common Lisp Reference Manual. The purpose of this document is to be a complete discription of all of ANSI Common Lisp. It differs from the Common Lisp standard or the Common Lisp HyperSpec, in that it is completely free (though I haven’t figured out the details
    [Show full text]