DOCSLIB.ORG

Common Lisp As an Embedded Extension Language

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Common Lisp As an Embedded Extension Language Common Lisp as an Embedded Extension Language A large part of HP PE/SolidDesigner’s user interface is written in Common Lisp. Common Lisp is also used as a user-accessible extension language. by Jens Kilian and HeinzĆPeter Arndt HP's PE/ME10 and PE/ME30 CAD systems contain anLisp extenĆ was invented by John McCarthy in 1956 during the sion language based on the macro expansion paradigm.Dartmouth The Summer Research Project on Artificial IntelliĆ user's input (commands and data) is separated intogence. single The first commonly used dialect was Lisp 1.5, but tokens, each of which denotes a command, function,unlike variĆ FORTRAN (or any other imperative language) Lisp is able, macro name, number, string, operator, or otherso syntacĆ easy to modify and extend that over time it acquired tic element. Commands, functions, and arithmetical expresĆcountless different dialects. For a long time, most Lisp sysĆ sions are evaluated by the language interpreter. Eachtems macro belonged to one of two major families, Interlisp and name is associated with a macro definition, whichMacLisp, is another but still differed in details. In 1981, discussions token sequence (either predefined by the system orabout defined a common Lisp language were begun. The goal was to by the user). When the language interpreter encountersdefine a a core language to be used as a base for future Lisp macro name, it substitutes the corresponding tokensystems. seĆ In 1984, the release of Common Lisp:1 The Language quence (this process isexpanding called the macro) and provided a first reference for the new language. An ANSI continues with the first token of the expansion. Technical Committee (X3J13) began to work on a formal standardization in 1985 and delivered a draft standard for Macro expansion languages are easy to implement and have Common Lisp in April 1992. This draft standard includes been used in many applications where one would hardly objectĆoriented programming features (the Common Lisp expect to find an embedded language. For example,X the T E Object System, or CLOS). For a more detailed account on the typesetting system contains a macro interpreter. evolution of Lisp, see McCarthy2 and Steele and Gabriel.3 The HP PE/ME10 and PE/ME30 macro language includes HCL, the implementation of Common Lisp used in HP PE/ powerful control constructs (suchIF/THEN/ELSE as andLOOP/ SolidDesigner, is derived from Austin Kyoto Common Lisp EXIT_IF/END_LOOP), local variables, and a mechanism for (itself descended from Kyoto Common Lisp). It corresponds passing parameters to a macro when it is being expanded. to the version of the language described in reference 1, but These constructs make it possible to solve general programĆ already incorporates some of the extensions from reference ming problems. Because the HP PE/ME10 and PE/ME30 4 and the draft standard. macro language is interpreted, programs can be developed in an interactive fashion and modifications can immediately Applications of Extension Languages be tried out. However, the resulting program is slower than a Adding extension languages to large application programs program written in a compiled language like C. HP PE/ME10 has become a standard practice. It provides many advanĆ and PE/ME30 macros can be compiled to an intermediate tages, some of which may be not as obvious as others. For form which executes faster than the pure interpreted verĆ the normal user of a system, an embedded programming sion, but which is still slower than an equivalent C program. language makes it possible to automate repetitive or tedious One disadvantage of the HP PE/ME10 and PE/ME30tasks. macro An inexperienced user can set it up as a simple reĆ language is that it is nonstandard. No other applicationcord/playback uses mechanism, while power users" can use it to the same language, and programs written in it havecreate to additional be functionality. If the extension language has ported when the user switches to another CAD system.ties to the application's user interface, userĆdefined functionĆ ality can be integrated as if it were part of the original Common Lisp application. Common Lisp was chosen as an extension language for HP If the application provides an API for adding extensions on a PE/SolidDesigner because it is nonproprietary and widely lower level, the extension language can itself be extended. used. This enables makers of valueĆadded software to integrate Surprising as it may be, Lisp is the second oldesttheir highĆlevel products seamlessly into the main application. As an programming language still in common use. The onlyexample, older the HP PE/SheetAdvisor application has been imĆ one is FORTRAN. Lisp is to researchers in artificialplemented intelliĆ within HP PE/ME30, offering a user interface gence what FORTRAN is to scientists and engineers.consistent with the rest of the program. October 1995 HewlettĆPackard Journal69 As a final step, portions of the application can themselvesThe article be on page 14 describes, from a user interface deĆ implemented in the embedded language. An exampleveloper's would perspective, how action routines are written and be the popular GNU Emacs text editor, a large parthow of menus which and dialogs are created. The mechanisms used is written in its embedded Lisp dialect. there are not part of the Common Lisp standard but are extensions provided by the HCL dialect. A large part of HP PE/SolidDesigner, too, is written in its own extension languageĊabout 30 percent at the time of Action Routines writing. Most of this 30 percent is in HP PE/SolidDesigner's Action routines implement the commands that a user types user interface. or issues via user interface elements to HP PE/SolidDesigner. Commands are identified by their names, which are Lisp Lisp in HP PE/SolidDesigner symbols evaluated in a special manner (similarSYM- to the Fig. 1 shows the major components of HP PE/SolidDesigner. BOL-MACROLET facility in the Common Lisp Object System). The Lisp subsystem is at the very core, together with the Each action routine is actually an interpreter for a small lanĆ Frame (operating system interface) and DSM (data structure guage, similar in syntax to the command language used in manager, see article, page 51) modules. All other compoĆ HP PE/ME10 and PE/ME30. Like HP PE/ME10 and PE/ME30 nents including Frame and DSM are embedded into the Lisp commands, action routines can be described by their syntax subsystem. This indicates that each component provides an diagrams. Fig. 2 contains the syntax diagram for a simplified interface through which its operations can be accessed by version of HP PE/SolidDesigner's exit command. Below the Lisp programs. syntax diagram is a state transition graph which shows how The introduction of new functionality into HP PE/SolidDeĆthe command will be processed. signer is usually done in the following steps: The definition of an action routine corresponds closely to its • Implement new data structures and operations in C++ syntax diagram. The defining Lisp expression, when evaluĆ • Add Lisp primitives (C++ functions callable from Lisp) for ated, generates a normal Lisp function that will traverse the accessing the new operations transition graph of the state machine when the action rouĆ • Add action routines to implement new userĆvisible tine is run. For example, the following is an action routine commands, using the Lisp interface to carry out the actual corresponding to the syntax diagram of Fig. 2: operations • Add menus, dialog boxes, or other graphical user(defaction interface simple_exit objects to access the new commands. (flag) ; local variable As long as the Lisp interfaceĊthe primitive functionsĊis (; state descriptions agreed to in advance, this process can be parallelized. A user interface specialist can work on the action routines (start and nil menus, calling dummy versions of the interface functions. “Terminate PE/SolidDesigner?” nil (:yes (setq flag t) answer-yes end) User Interface (:no (setq flag nil) answer-no end) (otherwise (display_error “Enter either :YES or :NO.”) nil start)) Links (end (do-it) (IGES, STEP, nil ...) nil)) K2 (; local functions Frame (do-it () Advanced (when flag HCL Blending (quit))))) DSM As can be seen in this example, an action routine can have local variables and functions. Local variables serve to carry PPG information from state to state. Local functions can reduce the amount of code present in the state descriptions, Advanced Local enhancing readability. Operations When HCL translates this action routine definition, it proĆ duces a Lisp function which, when run, traverses the state transition graph shown in Fig. 2b. If a state description conĆ tains a prompt string, asstart in state the in the example, the Fig. 1. HP PE/SolidDesigner system architecture. HCL is thetranslator automatically adds code for issuing the prompt Common Lisp subsystem. All components including Frame and reading user input. Effectively, the translator converts (operating system interface) and DSM (data structure manager)the simple syntax diagram into the more detailed form. have interfaces to Lisp. K2 is the solid modeling kernel. PPG is the planar profile generator. 70October 1995 HewlettĆPackard Journal simple_exit :YES ;; exit from action routine :NO (return)))))) (a) Transitions in the state machine are transformedgoto into :YES statements within the function's body. The conditional conĆ set flag = t structcond represents decisions, like the threeĆway branch in issue prompt wait for statestart. Before each state transition, the code can trigger start input end :NO an external event to enable graphical feedback in menus or set flag = nil dialogs. other input issue error message The actual translation is somewhat more complicated beĆ cause errors and other exceptional events must be taken into (b) account. The translator also adds code to support debugging Fig. 2.(a) Simplified syntax of the exit command. (b) Stateand profiling of an action routine.
Load more

Recommended publications
  • Introduction to Programming in Lisp
    Introduction to Programming in Lisp Supplementary handout for 4th Year AI lectures · D W Murray · Hilary 1991 1 Background There are two widely used languages for AI, viz. Lisp and Prolog. The latter is the language for Logic Programming, but much of the remainder of the work is programmed in Lisp. Lisp is the general language for AI because it allows us to manipulate symbols and ideas in a commonsense manner. Lisp is an acronym for List Processing, a reference to the basic syntax of the language and aim of the language. The earliest list processing language was in fact IPL developed in the mid 1950’s by Simon, Newell and Shaw. Lisp itself was conceived by John McCarthy and students in the late 1950’s for use in the newly-named field of artificial intelligence. It caught on quickly in MIT’s AI Project, was implemented on the IBM 704 and by 1962 to spread through other AI groups. AI is still the largest application area for the language, but the removal of many of the flaws of early versions of the language have resulted in its gaining somewhat wider acceptance. One snag with Lisp is that although it started out as a very pure language based on mathematic logic, practical pressures mean that it has grown. There were many dialects which threaten the unity of the language, but recently there was a concerted effort to develop a more standard Lisp, viz. Common Lisp. Other Lisps you may hear of are FranzLisp, MacLisp, InterLisp, Cambridge Lisp, Le Lisp, ... Some good things about Lisp are: • Lisp is an early example of an interpreted language (though it can be compiled).
    [Show full text]
  • High-Level Language Features Not Found in Ordinary LISP. the GLISP
    DOCUMENT RESUME ED 232 860 SE 042 634 AUTHOR Novak, Gordon S., Jr. TITLE GLISP User's Manual. Revised. INSTITUTION Stanford Univ., Calif. Dept. of Computer Science. SPONS AGENCY Advanced Research Projects Agency (DOD), Washington, D.C.; National Science Foundation, Washington, D.C. PUB DATE 23 Nov 82 CONTRACT MDA-903-80-c-007 GRANT SED-7912803 NOTE 43p.; For related documents, see SE 042 630-635. PUB TYPE Guides General (050) Reference Materials General (130) EDRS PRICE MF01/PCO2 Plus Postage. DESCRIPTORS *Computer Programs; *Computer Science; Guides; *Programing; *Programing Languages; *Resource Materials IDENTIFIERS *GLISP Programing Language; National Science Foundation ABSTRACT GLISP is a LISP-based language which provides high-level language features not found in ordinary LISP. The GLISP language is implemented by means of a compiler which accepts GLISP as input and produces ordinary LISP as output. This output can be further compiled to machine code by the LISP compiler. GLISP is available for several ISP dialects, including Interlisp, Maclisp, UCI Lisp, ELISP, Franz Lisp, and Portable Standard Lisp. The goal of GLISP is to allow structured objects to be referenced in a convenient, succinct language and to allow the structures of objects to be changed without changing the code which references the objects. GLISP provides both PASCAL-like and English-like syntaxes; much of the power and brevity of GLISP derive from the compiler features necessary to support the relatively informal, English-like language constructs. Provided in this manual is the documentation necessary for using GLISP. The documentation is presented in the following sections: introduction; object descriptions; reference to objects; GLISP program syntax; messages; context rules and reference; GLISP and knowledge representation languages; obtaining and using GLISP; GLISP hacks (some ways of doing things in GLISP which might not be entirely obvious at first glance); and examples of GLISP object declarations and programs.
    [Show full text]
  • 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]
  • The Evolution of Lisp
    1 The Evolution of Lisp Guy L. Steele Jr. Richard P. Gabriel Thinking Machines Corporation Lucid, Inc. 245 First Street 707 Laurel Street Cambridge, Massachusetts 02142 Menlo Park, California 94025 Phone: (617) 234-2860 Phone: (415) 329-8400 FAX: (617) 243-4444 FAX: (415) 329-8480 E-mail: [email protected] E-mail: [email protected] Abstract Lisp is the world’s greatest programming language—or so its proponents think. The structure of Lisp makes it easy to extend the language or even to implement entirely new dialects without starting from scratch. Overall, the evolution of Lisp has been guided more by institutional rivalry, one-upsmanship, and the glee born of technical cleverness that is characteristic of the “hacker culture” than by sober assessments of technical requirements. Nevertheless this process has eventually produced both an industrial- strength programming language, messy but powerful, and a technically pure dialect, small but powerful, that is suitable for use by programming-language theoreticians. We pick up where McCarthy’s paper in the first HOPL conference left off. We trace the development chronologically from the era of the PDP-6, through the heyday of Interlisp and MacLisp, past the ascension and decline of special purpose Lisp machines, to the present era of standardization activities. We then examine the technical evolution of a few representative language features, including both some notable successes and some notable failures, that illuminate design issues that distinguish Lisp from other programming languages. We also discuss the use of Lisp as a laboratory for designing other programming languages. We conclude with some reflections on the forces that have driven the evolution of Lisp.
    [Show full text]
  • Allegro CL User Guide
    Allegro CL User Guide Volume 1 (of 2) version 4.3 March, 1996 Copyright and other notices: This is revision 6 of this manual. This manual has Franz Inc. document number D-U-00-000-01-60320-1-6. Copyright 1985-1996 by Franz Inc. All rights reserved. No part of this pub- lication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means electronic, mechanical, by photocopying or recording, or otherwise, without the prior and explicit written permission of Franz incorpo- rated. Restricted rights legend: Use, duplication, and disclosure by the United States Government are subject to Restricted Rights for Commercial Software devel- oped at private expense as specified in DOD FAR 52.227-7013 (c) (1) (ii). Allegro CL and Allegro Composer are registered trademarks of Franz Inc. Allegro Common Windows, Allegro Presto, Allegro Runtime, and Allegro Matrix are trademarks of Franz inc. Unix is a trademark of AT&T. The Allegro CL software as provided may contain material copyright Xerox Corp. and the Open Systems Foundation. All such material is used and distrib- uted with permission. Other, uncopyrighted material originally developed at MIT and at CMU is also included. Appendix B is a reproduction of chapters 5 and 6 of The Art of the Metaobject Protocol by G. Kiczales, J. des Rivieres, and D. Bobrow. All this material is used with permission and we thank the authors and their publishers for letting us reproduce their material. Contents Volume 1 Preface 1 Introduction 1.1 The language 1-1 1.2 History 1-1 1.3 Format
    [Show full text]
  • Writing a Best-Effort Portable Code Walker in Common Lisp
    Writing a best-effort portable code walker in Common Lisp Michael Raskin∗ LaBRI, University of Bordeaux [email protected] ABSTRACT ACM Reference format: One of the powerful features of the Lisp language family is Michael Raskin. 2017. Writing a best-effort portable code walker possibility to extend the language using macros. Some of in Common Lisp. In Proceedings of 10th European Lisp Simpo- sium, Vrije Universiteit Brussel, Belgium, April 2017 (ELS2017), possible extensions would benefit from a code walker, i.e. a 8 pages. library for processing code that keeps track of the status DOI: 10.5281/zenodo.3254669 of different part of code, for their implementation. But in practice code walking is generally avoided. In this paper, we study facilities useful to code walkers 1 INTRODUCTION provided by \Common Lisp: the Language" (2nd edition) and the Common Lisp standard. We will show that the Much of the power of Common Lisp comes from its extensibil- features described in the standard are not sufficient to write ity. Abstractions that cannot be expressed by functions can a fully portable code walker. still be expressed by macros; actually, many of the features One of the problems is related to a powerful but rarely described in the standard must be implemented as macros. discussed feature. The macrolet special form allows a macro Whilst macros are powerful on their own, some ways of function to pass information easily to other macro invocations extending Lisp would benefit from using higher-level code inside the lexical scope of the expansion. transformation abstractions. For many such abstractions the Another problem for code analysis is related to the usage of most natural way to implement them includes code walk- non-standard special forms in expansions of standard macros.
    [Show full text]
  • A Lisp Oriented Architecture by John W.F
    A Lisp Oriented Architecture by John W.F. McClain Submitted to the Department of Electrical Engineering and Computer Science in partial fulfillment of the requirements for the degrees of Master of Science in Electrical Engineering and Computer Science and Bachelor of Science in Electrical Engineering at the MASSACHUSETTS INSTITUTE OF TECHNOLOGY September 1994 © John W.F. McClain, 1994 The author hereby grants to MIT permission to reproduce and to distribute copies of this thesis document in whole or in part. Signature of Author ...... ;......................... .............. Department of Electrical Engineering and Computer Science August 5th, 1994 Certified by....... ......... ... ...... Th nas F. Knight Jr. Principal Research Scientist 1,,IA £ . Thesis Supervisor Accepted by ....................... 3Frederic R. Morgenthaler Chairman, Depattee, on Graduate Students J 'FROM e ;; "N MfLIT oARIES ..- A Lisp Oriented Architecture by John W.F. McClain Submitted to the Department of Electrical Engineering and Computer Science on August 5th, 1994, in partial fulfillment of the requirements for the degrees of Master of Science in Electrical Engineering and Computer Science and Bachelor of Science in Electrical Engineering Abstract In this thesis I describe LOOP, a new architecture for the efficient execution of pro- grams written in Lisp like languages. LOOP allows Lisp programs to run at high speed without sacrificing safety or ease of programming. LOOP is a 64 bit, long in- struction word architecture with support for generic arithmetic, 64 bit tagged IEEE floats, low cost fine grained read and write barriers, and fast traps. I make estimates for how much these Lisp specific features cost and how much they may speed up the execution of programs written in Lisp.
    [Show full text]
  • Common Lisp Ultraspec – a Project for Modern Common Lisp Documentation
    Common Lisp UltraSpec – A Project For Modern Common Lisp Documentation Michał „phoe” Herda #lisp-pl @ Freenode Jagiellonian University, Cracow, Poland Previously on European Lisp Symposium 2016 Yet Another Rant About The State Of Common Lisp Documentation Michał „phoe” Herda Presenting the European Lisp Symposium 2017 Exclusive: Yet Another Rant About The State Of Common Lisp Documentation, Part 2 Michał „phoe” Herda http://www.lispworks.com/documentation/HyperSpec/... http://www.sbcl.org/manual/... http://ccl.clozure.com/manual/... http://www.clisp.org/... http://bauhh.dyndns.org:8000/clim-spec/... http://bauhh.de/clxman/... http://metamodular.com/CLOS-MOP/... 50+(?) more websites with library-specific docs Fin, Part 2 (...except it’s not) A Possible Solution To The State Of Common Lisp Documentation, Part 2 Michał „phoe” Herda Parsing dpANS with RegEx Parsing HTML (context-free grammar) with RegEx (regular grammar): Parsing TeX (context-sensitive grammar) with RegEx (regular grammar): Parsing a known subset of TeX used in dpANS with RegEx (regular grammar): (with proper care) What’s done so far? ● Done ● All Dictionaries (e.g. MAPCAR, ADJOIN, …) ● Glossary ● Not done / TODO ● Concepts (e.g. 2.2 Reader Algorithm) ● Linking (esp. glossary entries) What’s done so far? ● Done ● All Dictionaries (e.g. MAPCAR, ADJOIN, …) ● Glossary ● Not done / TODO ● Concepts (e.g. 2.2 Reader Algorithm) ● Linking (esp. glossary entries) ● Review ● Diffs to the original dpANS ● Once it’s finished, SHIP IT! What am I aiming for? Editable Complete Downloadable
    [Show full text]
  • A Note on the Optimal Allocation of Spaces in MACLISP by Henry C
    MASSACHUSETTS INSTITUTE OF TECHNOLOGY ARTIFICIAL INTELLIGENCE LABORATORY Al Working Paper 142 March 16, 1977 A Note on the Optimal Allocation of Spaces in MACLISP by Henry C. Baker, Jr. This note describes a method for allocating storage among the various spaces in the MACLISP Implementation of LISP. The optimal strategy which minimizes garbage collector effort allocates free storage among the various spaces in snch a way that they all run out at the same time. In an equilibrium situation, this corresponds to allocating free storage to the spaces in proportion to their usage. Methods are investigated by which the rates of usage can be inferred, and a ge-daemon interrupt handler is developed which implements an approximately optimal strategy in MACLISP. Finally, the sensitivity of this method to rapidly varying differential rates of cell usage is discussed. Key Words and Phrases: garbage collection, list processing, virtual memory, storage management, storage allocation, LISP. CR Categories: 3.50, 3.60, 3.73, 3.80, 4.13, 422, 4.32, 4.33, 4.35, 4.49 This report describes research done at the Artificial Intelligence Laboratory of the Massachusetts Institute of Technology. Support for the laboratory's artificial intelligence research is provided in part by the Advanced Research Projects Agency of the Department of Defense under Office of Naval Research contract N00014-75-C-0522. Working Papers are informal papers intended for internal use. March 16, 1977 A Note on the Optimal Allocation of Spaces in MACLISP Henry C. Baker, Jr. MACLISP [11 unlike some other implementations of. LISP, allocates storage for different types of objects in non-contiguous areas called spaces.
    [Show full text]
  • Commonloops Merging Lisp and Object-Oriented Programming Daniel G
    CommonLoops Merging Lisp and Object-Oriented Programming Daniel G. Bobrow, Kenneth Kahn, Gregor Kiczales, Larry Masinter, Mark Stefik, and Frank Zdybel Xerox Palo Alto Research Center Palo Alto, California 94304 CommonLoops blends object-oriented programming Within the procedure-oriented paradigm, Lisp smoothly and tightly with the procedure-oriented provides an important approach for factoring design of Lisp. Functions and methods are combined programs that is'different from common practice in in a more general abstraction. Message passing is object-oriented programming. In this paper we inuoked via normal Lisp function call. Methods are present the linguistic mechanisms that we have viewed as partial descriptions of procedures. Lisp data developed for integrating these styles. We argue that types are integrated with object classes. With these the unification results in something greater than the integrations, it is easy to incrementally move a program sum of the parts, that is, that the mechanisms needed between the procedure and object -oriented styles. for integrating object-oriented and procedure-oriented approaches give CommonLoops surprising strength. One of the most important properties of CommonLoops is its extenswe use of meta-objects. We discuss three We describe a smooth integration of these ideas that kinds of meta-objects: objects for classes, objects for can work efficiently in Lisp systems implemented on a methods, and objects for discriminators. We argue that wide variety of machines. We chose the Common Lisp these meta-objects make practical both efficient dialect as a base on which to bui|d CommonLoops (a implementation and experimentation with new ideas Common Lisp Object-Oriented Programming System).
    [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]
  • Special Topics: Programming Languages
    Lecture #11 • 0 V22.0490.001 Special Topics: Programming Languages B. Mishra New York University. Lecture # 11 Programming Languages • MISHRA 2008 Lecture #11 • 1 —Slide 1— Common Lisp Language Survey 4 Functional Programming • Pure Functional Programming: Implicit Principle ◦ The value of an expression depends only on the values of its subexpressions, if any. – No side-effect. (No State—No assignment) – An expression has the same value, every time. – Implicit Storage Management: Allocation on Demand + Garbage Collection. – Functions are First Class Objects: 1) As value of an expression 2) As parameters 3) As data Objects. Programming Languages • MISHRA 2008 Lecture #11 • 2 —Slide 2— Common Lisp • LISP: LIst Processing Language Not— Lots of Insidious Sill Parentheses • Second oldest Programming Language (Af- ter Fortran) • Application Areas: 1. Theorem Proving 2. Symbolic Algebra 3. AI (Artificial Intelligence) (Natural Language Processing, Com- puter Vision, Robot Control Systems, Ex- pert Systems, Neural Networks, Automatic Programming) Programming Languages • MISHRA 2008 Lecture #11 • 3 —Slide 3— HISTORY • Developed at MIT AI Lab—1959. LISP 1.5 running on an IBM machine. • BBN LISP (PDP 1/SDS 940) became → INTERLISP (PDP 10) • MACLISP (MIT Project MAC) • LISP 1.6—A version of MACLISP ◦ UCI-LISP (Univ. of Cal. at Irvine) ◦ Standard Lisp (Univ. of Utah) • Lisp Machine Lisp Large Personal Lisp Machine built at MIT • FranzLISP for Vax/UNIX (UC Berkeley) • NIL for Vax/VMS (MIT) • Scheme at MIT • T Lisp at Yale Programming Languages • MISHRA 2008 Lecture #11 • 4 —Slide 4— Common Lisp • 1981/Carnegie-Mellon/Guy L. Steele • Clean Lisp Inconsistencies and illogical conventions were resolved • Transportable Programs written in Common Lisp and debugged in one implementation should run on another ma- chine/implementation without change.
    [Show full text]