Tutorial on Good Lisp Programming Style

Total Page:16

File Type:pdf, Size:1020Kb

Tutorial on Good Lisp Programming Style Lisp Users and Vendors Conference August Tutorial on Go o d Lisp Programming Style Peter Norvig Sun Microsystems Labs Inc Kent Pitman Harlequin Inc c Portions copyright Peter Norvig c Portions copyright Kent M Pitman All Rights Reserved Outline What is Go o d Style Tips on BuiltIn Functionality Tips on NearStandard Tools Kinds of Abstraction Programming in the Large Miscellaneous What is Go o d Style Good Lisp Programming Style Elegance is not optional Richard A OKeefe Good style in any language leads to programs that are Understandable Reusable Extensible Ecient Easy to developdebug It also helps correctness robustness compatibility Our maxims of go o d style are Be explicit Be sp ecic Be concise Be consistent Be helpful anticipate the readers needs Be conventional dont b e obscure Build abstractions at a usable level Allow to ols to interact referential transparency Good style is the underware that supp ortsaprogram Where do es go o d style come from What To Believe Dont b elieve everything we tell you Just most Worry less ab out what to b elieve and more ab out why Know where your Style Rules come from Religion Go o d vs Evil This way is b etter Philosophy This is consistent with other things Robustness Liability Safety Ethics Ill put in redundant checks to avoid something horrible Legality Our lawyers say do it this way Personality Opinion I like it this way Compatibility Another to ol exp ects this way Portability Other compilers prefer this way Co op eration Convention It has to be done some uniform waysowe agreed on this one Habit Tradition Weve always done it this way Ability My programmers arent sophisticated enough Memory Knowing how I would do it means I dont have to rememb er howIdid do it Sup erstition Im scared to do it dierently Practicality This makes other things easier Where do es go o d style come from Its All Ab out Communication Expression Understanding Communication Programs communicate with Human readers Compilers Text editors arglist do c string indent To ols trace step aprop os xref manual Users of the program indirect communication Where do es go o d style come from Know the Context When reading co de Know who wrote it and when When writing co de Annotate it with comments Sign and date your comments Should b e an editor command to do this Some things to notice Peoples style changes over time The same p erson at dierent times can seem like a dierent p erson Sometimes that p erson is you How do I knowifitsgood Value Systems Are Not Absolute Style rules cannot b e viewed in isolation They often overlap in conicting ways The fact that style rules conict with one another re ects the natural fact that realworld goals conict A good programmer makes tradeos in programming style that reect underlying priority choices among var ious major goals Understandable Reusable Extensible Ecient co ding space sp eed Easy to developdebug How do I knowifitsgood Why Go o d Style is Go o d Good style helps build the current program and the next one Organizes a program relieving human memory needs Encourages mo dular reusable parts Style is not just added at the end It plays a part in Organization of the program into les Toplevel design structure and layout of each le Decomp osition into mo dules and comp onents Datastructure choice Individual function designimplementation Naming formatting and do cumenting standards How do I knowifitsgood Why Style is Practical Memory When I was young I could imagine a castle with twenty ro oms with each ro om having ten dierent ob jects in it I would have no problem I cant do that anymore Now I think more in terms of earlier exp eri ences I see a network of inchoate clouds instead of the picturep ostcard clearness But I do write b etter programs Charles Simonyi Some p eople are go o d programmers b ecause they can handle many more details than most p eople But there are a lot of disadvantages in selecting programmers for that reasonit can result in programs no on else can maintain Butler Lampson Pick out any three lines in my program and I can tell you where theyre from and what they do David McDonald Good style replaces the need for great memory Make sure any lines are selfexplanatory Also called referential transparency Package complexity into objects and abstractions not global variablesdep endencies Make it fractally selforganizing all the way updown Saywhatyou mean Mean what you say How do I knowifitsgood Why Style is Practical Reuse Structured Programming encourages mo dules that meet sp ecications and can b e reused within the b ounds of that sp ecication Stratied Design encourages mo dules with commonly needed functionality which can be reused even when the sp ecication changes or in another program ObjectOriented Design is stratied design that con centrates on classes of objects and on information hid ing You should aim to reuse Data typ es classes Functions metho ds Control abstractions Interface abstractions packages mo dules Syntactic abstractions macros and whole languages How do I knowifitsgood Say What You Mean Saywhatyou mean simply and directly Kernighan Plauger Say what you mean in data b e sp ecic concise Use data abstractions Dene languages for data if needed Cho ose names wisely Say what you mean in co de b e concise conventional Dene interfaces clearly Use Macros and languages appropriately Use builtin functions Create your own abstractions Dont do it twice if you can do it once In annotations b e explicit helpful Use appropriate detail for comments Do cumentation strings are b etter than comments Saywhatitisfor not just what it do es Declarations and assertions Systems and test les etc How do I knowifitsgood Be Explicit Optional and Keyword arguments If you have to lo ok up the default value you need to supply it You should only take the default if you truly b elieve you dont care or if youre sure the default is wellundersto o d and wellaccepted byall For example when op ening a le you should almost never consider omitting the direction keyword argu ment even though you know it will default to input Declarations If you knowtyp e information declare it Dont do what some p eople do and only declare things you know the compiler will use Compilers change and you want your program to naturally take advantage of those changes without the need for ongoing intervention Also declarations are for communication with human readers to onot just compilers Comments If youre thinking of something useful that others might want to know when they read your co de and that might not b e instantly apparent to them make it a comment How do I knowifitsgood Be Sp ecic Be as sp ecic as your data abstractions warrant but no more Cho ose more specific more abstract mapc processword map nil processword first sentences elt sentences Most sp ecic conditional if fortwobranch expression when unless foronebranch statement and or for b o olean value only cond for multibranch statement or expression Violates Expectation Follows Expectation and numberp x cos x and numberp x x if numberp x cos x if numberp x cos x nil if numberp x print x when numberp x print x How do I knowifitsgood Be Concise Test for the simplest case If you make the same test or return the same result in two places there must b e an easier way Bad verb ose convoluted defun countallnumbers alist cond null alist t if listp first alist countallnumbers first alist if numberp first alist countallnumbers rest alist Returns twice Nonstandard indentation alist suggests asso ciation list Good defun countallnumbers exp typecase exp cons countallnumbers first exp countallnumbers rest exp number t cond instead of typecase is equally go o d less sp ecic more conventional consistent How do I knowifitsgood Be Concise Maximize LOCNW lines of co de not written Shorter is b etter and shortest is b est Jim Meehan Bad to o verb ose inecient defun vectoradd x y let z nil n setq n min listlength x listlength y dotimes j n reverse z setq z cons nth j x nth j y z defun matrixadd A B let C nil m setq m min listlength A listlength B dotimes i m reverse C setq C cons vectoradd nth i A nth i B C Use of nth makes this O n Why listlength Why not length or mapcar Why not nreverse Why not use arrays to implement arrays The return value is hidden How do I knowifitsgood Be Concise Better more concise defun vectoradd x y Elementwise add of two vectors mapcar x y defun matrixadd A B Elementwise add of two matrices lists of lists mapcar vectoradd A B Or use generic functions defun add rest args Generic addition if null args reduce binaryadd args defmethod binaryadd x number y number x y defmethod binaryadd x sequence y sequence map typeof x binaryadd x y How do I knowifitsgood Be Helpful Do cumentation should b e organized around tasks the user needs to do not around what your program hap p ens to provide Adding do cumentation strings to each function usually do esnt tell the reader how to use your program but hints in the right place can be very ef fective Good from Gnu Emacs online help nextline Move cursor vertically down ARG lines If you are thinking of usingthisinaLispprogram consider using forwardline instead It is usually eas ier to use and more reliable no dep endence on goal column etc defun denes NAME as a function The denition is lambda ARGLIST DOCSTRING BODY See also the function interactive These anticipate users use and problems How do I knowifitsgood Be Conventional Build your own
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]
  • A Concurrent PASCAL Compiler for Minicomputers
    512 Appendix A DIFFERENCES BETWEEN UCSD'S PASCAL AND STANDARD PASCAL The PASCAL language used in this book contains most of the features described by K. Jensen and N. Wirth in PASCAL User Manual and Report, Springer Verlag, 1975. We refer to the PASCAL defined by Jensen and Wirth as "Standard" PASCAL, because of its widespread acceptance even though no international standard for the language has yet been established. The PASCAL used in this book has been implemented at University of California San Diego (UCSD) in a complete software system for use on a variety of small stand-alone microcomputers. This will be referred to as "UCSD PASCAL", which differs from the standard by a small number of omissions, a very small number of alterations, and several extensions. This appendix provides a very brief summary Of these differences. Only the PASCAL constructs used within this book will be mentioned herein. Documents are available from the author's group at UCSD describing UCSD PASCAL in detail. 1. CASE Statements Jensen & Wirth state that if there is no label equal to the value of the case statement selector, then the result of the case statement is undefined. UCSD PASCAL treats this situation by leaving the case statement normally with no action being taken. 2. Comments In UCSD PASCAL, a comment appears between the delimiting symbols "(*" and "*)". If the opening delimiter is followed immediately by a dollar sign, as in "(*$", then the remainder of the comment is treated as a directive to the compiler. The only compiler directive mentioned in this book is (*$G+*), which tells the compiler to allow the use of GOTO statements.
    [Show full text]
  • Open Office Specification 1.0
    Open Office Specification 1.0 Committee Draft 1, 22 Mar 2004 Document identifier: office-spec-1.0-cd-1.sxw Location: http://www.oasis-open.org/committees/office/ Editors: Michael Brauer, Sun Microsystems <[email protected]> Gary Edwards <[email protected]> Daniel Vogelheim, Sun Microsystems <[email protected]> Contributors: Doug Alberg, Boeing <[email protected]> Simon Davis, National Archive of Australia <[email protected]> Patrick Durusau, Society of Biblical Literature <[email protected]> David Faure, <[email protected]> Paul Grosso, Arbortext <[email protected]> Tom Magliery, Blast Radius <[email protected]> Phil Boutros, Stellent <[email protected]> John Chelsom, CSW Informatics <[email protected]> Jason Harrop, SpeedLegal <[email protected]> Mark Heller, New York State Office of the Attorney General <[email protected]> Paul Langille, Corel <[email protected]> Monica Martin, Drake Certivo <[email protected]> Uche Ogbuji <[email protected]> Lauren Wood <[email protected]> Abstract: This is the specification of Open Office XML, an open, XML-based file format for office applications, based on OpenOffice.org XML [OOo]. Status: This document is a draft, and will be updated periodically on no particular schedule. Send comments to the editors. Committee members should send comments on this specification to the [email protected] list. Others should subscribe to and send comments to the [email protected] list. To subscribe, send an email message to office- [email protected] with the word "subscribe" as the body of the message.
    [Show full text]
  • Praise for Practical Common Lisp
    Praise for Practical Common Lisp “Finally, a Lisp book for the rest of us. If you want to learn how to write a factorial function, this is not your book. Seibel writes for the practical programmer, emphasizing the engineer/artist over the scientist and subtly and gracefully implying the power of the language while solving understandable real-world problems. “In most chapters, the reading of the chapter feels just like the experience of writing a program, starting with a little understanding and then having that understanding grow, like building the shoulders upon which you can then stand. When Seibel introduced macros as an aside while building a test frame- work, I was shocked at how such a simple example made me really ‘get’ them. Narrative context is extremely powerful, and the technical books that use it are a cut above. Congrats!” —Keith Irwin, Lisp programmer “While learning Lisp, one is often referred to the CL HyperSpec if they do not know what a particular function does; however, I found that I often did not ‘get it’ just by reading the HyperSpec. When I had a problem of this manner, I turned to Practical Common Lisp every single time—it is by far the most readable source on the subject that shows you how to program, not just tells you.” —Philip Haddad, Lisp programmer “With the IT world evolving at an ever-increasing pace, professionals need the most powerful tools available. This is why Common Lisp—the most powerful, flexible, and stable programming language ever—is seeing such a rise in popu- larity.
    [Show full text]
  • PUB DAM Oct 67 CONTRACT N00014-83-6-0148; N00014-83-K-0655 NOTE 63P
    DOCUMENT RESUME ED 290 438 IR 012 986 AUTHOR Cunningham, Robert E.; And Others TITLE Chips: A Tool for Developing Software Interfaces Interactively. INSTITUTION Pittsburgh Univ., Pa. Learning Research and Development Center. SPANS AGENCY Office of Naval Research, Arlington, Va. REPORT NO TR-LEP-4 PUB DAM Oct 67 CONTRACT N00014-83-6-0148; N00014-83-K-0655 NOTE 63p. PUB TYPE Reports - Research/Technical (143) EDRS PRICE MF01/PC03 Plus Postage. DESCRIPTORS *Computer Graphics; *Man Machine Systems; Menu Driven Software; Programing; *Programing Languages IDENTIF7ERS Direct Manipulation Interface' Interface Design Theory; *Learning Research and Development Center; LISP Programing Language; Object Oriented Programing ABSTRACT This report provides a detailed description of Chips, an interactive tool for developing software employing graphical/computer interfaces on Xerox Lisp machines. It is noted that Chips, which is implemented as a collection of customizable classes, provides the programmer with a rich graphical interface for the creation of rich graphical interfaces, and the end-user with classes for modeling the graphical relationships of objects on the screen and maintaining constraints between them. This description of the system is divided into five main sections: () the introduction, which provides background material and a general description of the system; (2) a brief overview of the report; (3) detailed explanations of the major features of Chips;(4) an in-depth discussion of the interactive aspects of the Chips development environment; and (5) an example session using Chips to develop and modify a small portion of an interface. Appended materials include descriptions of four programming techniques that have been sound useful in the development of Chips; descriptions of several systems developed at the Learning Research and Development Centel tsing Chips; and a glossary of key terms used in the report.
    [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]
  • From JSON to JSEN Through Virtual Languages of the Creative Commons Attribution License (
    © 2021 by the authors; licensee RonPub, Lübeck, Germany. This article is an open access article distributed under the terms and conditions A.of Ceravola, the Creative F. Joublin:Commons From Attribution JSON to license JSEN through(http://c reativecommons.org/licenses/by/4Virtual Languages .0/). Open Access Open Journal of Web Technology (OJWT) Volume 8, Issue 1, 2021 www.ronpub.com/ojwt ISSN 2199-188X From JSON to JSEN through Virtual Languages Antonello Ceravola, Frank Joublin Honda Research Institute Europe GmbH, Carl Legien Str. 30, Offenbach/Main, Germany, {Antonello.Ceravola, Frank.Joublin}@honda-ri.de ABSTRACT In this paper we describe a data format suitable for storing and manipulating executable language statements that can be used for exchanging/storing programs, executing them concurrently and extending homoiconicity of the hosting language. We call it JSEN, JavaScript Executable Notation, which represents the counterpart of JSON, JavaScript Object Notation. JSON and JSEN complement each other. The former is a data format for storing and representing objects and data, while the latter has been created for exchanging/storing/executing and manipulating statements of programs. The two formats, JSON and JSEN, share some common properties, reviewed in this paper with a more extensive analysis on what the JSEN data format can provide. JSEN extends homoiconicity of the hosting language (in our case JavaScript), giving the possibility to manipulate programs in a finer grain manner than what is currently possible. This property makes definition of virtual languages (or DSL) simple and straightforward. Moreover, JSEN provides a base for implementing a type of concurrent multitasking for a single-threaded language like JavaScript.
    [Show full text]
  • Inf 212 Analysis of Prog. Langs Elements of Imperative Programming Style
    INF 212 ANALYSIS OF PROG. LANGS ELEMENTS OF IMPERATIVE PROGRAMMING STYLE Instructors: Kaj Dreef Copyright © Instructors. Objectives Level up on things that you may already know… ! Machine model of imperative programs ! Structured vs. unstructured control flow ! Assignment ! Variables and names ! Lexical scope and blocks ! Expressions and statements …so to understand existing languages better Imperative Programming 3 Oldest and most popular paradigm ! Fortran, Algol, C, Java … Mirrors computer architecture ! In a von Neumann machine, memory holds instructions and data Control-flow statements ! Conditional and unconditional (GO TO) branches, loops Key operation: assignment ! Side effect: updating state (i.e., memory) of the machine Simplified Machine Model 4 Registers Code Data Stack Program counter Environment Heap pointer Memory Management 5 Registers, Code segment, Program counter ! Ignore registers (for our purposes) and details of instruction set Data segment ! Stack contains data related to block entry/exit ! Heap contains data of varying lifetime ! Environment pointer points to current stack position ■ Block entry: add new activation record to stack ■ Block exit: remove most recent activation record Control Flow 6 Control flow in imperative languages is most often designed to be sequential ! Instructions executed in order they are written ! Some also support concurrent execution (Java) But… Goto in C # include <stdio.h> int main(){ float num,average,sum; int i,n; printf("Maximum no. of inputs: "); scanf("%d",&n); for(i=1;i<=n;++i){
    [Show full text]
  • Jalopy User's Guide V. 1.9.4
    Jalopy - User’s Guide v. 1.9.4 Jalopy - User’s Guide v. 1.9.4 Copyright © 2003-2010 TRIEMAX Software Contents Acknowledgments . vii Introduction . ix PART I Core . 1 CHAPTER 1 Installation . 3 1.1 System requirements . 3 1.2 Prerequisites . 3 1.3 Wizard Installation . 4 1.3.1 Welcome . 4 1.3.2 License Agreement . 5 1.3.3 Installation Features . 5 1.3.4 Online Help System (optional) . 8 1.3.5 Settings Import (optional) . 9 1.3.6 Configure plug-in Defaults . 10 1.3.7 Confirmation . 11 1.3.8 Installation . 12 1.3.9 Finish . 13 1.4 Silent Installation . 14 1.5 Manual Installation . 16 CHAPTER 2 Configuration . 17 2.1 Overview . 17 2.1.1 Preferences GUI . 18 2.1.2 Settings files . 29 2.2 Global . 29 2.2.1 General . 29 2.2.2 Misc . 32 2.2.3 Auto . 35 2.3 File Types . 36 2.3.1 File types . 36 2.3.2 File extensions . 37 2.4 Environment . 38 2.4.1 Custom variables . 38 2.4.2 System variables . 40 2.4.3 Local variables . 41 2.4.4 Usage . 42 2.4.5 Date/Time . 44 2.5 Exclusions . 44 2.5.1 Exclusion patterns . 45 2.6 Messages . 46 2.6.1 Categories . 47 2.6.2 Logging . 48 2.6.3 Misc . 49 2.7 Repository . 49 2.7.1 Searching the repository . 50 2.7.2 Displaying info about the repository . 50 2.7.3 Adding libraries to the repository . 50 2.7.4 Removing the repository .
    [Show full text]
  • C Style and Coding Standards
    -- -- -1- C Style and Coding Standards Glenn Skinner Suryakanta Shah Bill Shannon AT&T Information System Sun Microsystems ABSTRACT This document describes a set of coding standards and recommendations for programs written in the C language at AT&T and Sun Microsystems. The purpose of having these standards is to facilitate sharing of each other’s code, as well as to enable construction of tools (e.g., editors, formatters). Through the use of these tools, programmers will be helped in the development of their programs. This document is based on a similar document written by L.W. Cannon, R.A. Elliott, L.W. Kirchhoff, J.H. Miller, J.M. Milner, R.W. Mitze, E.P. Schan, N.O. Whittington at Bell Labs. -- -- -2- C Style and Coding Standards Glenn Skinner Suryakanta Shah Bill Shannon AT&T Information System Sun Microsystems 1. Introduction The scope of this document is the coding style used at AT&T and Sun in writing C programs. A common coding style makes it easier for several people to cooperate in the development of the same program. Using uniform coding style to develop systems will improve readability and facilitate maintenance. In addition, it will enable the construction of tools that incorporate knowledge of these standards to help programmers in the development of programs. For certain style issues, such as the number of spaces used for indentation and the format of variable declarations, no clear consensus exists. In these cases, we have documented the various styles that are most frequently used. We strongly recommend, however, that within a particular project, and certainly within a package or module, only one style be employed.
    [Show full text]
  • S Allegro Common Lisp Foreign Function Interface
    Please do not remove this page Extensions to the Franz, Inc.'s Allegro Common Lisp foreign function interface Keane, John https://scholarship.libraries.rutgers.edu/discovery/delivery/01RUT_INST:ResearchRepository/12643408560004646?l#13643533500004646 Keane, J. (1996). Extensions to the Franz, Inc.’s Allegro Common Lisp foreign function interface. Rutgers University. https://doi.org/10.7282/t3-pqns-7h57 This work is protected by copyright. You are free to use this resource, with proper attribution, for research and educational purposes. Other uses, such as reproduction or publication, may require the permission of the copyright holder. Downloaded On 2021/09/29 22:58:32 -0400 Extensions to the Franz Incs Allegro Common Lisp Foreign Function Interface John Keane Department of Computer Science Rutgers University New Brunswick NJ keanecsrutgersedu January Abstract As provided by Franz Inc the foreign function interface of Allegro Com mon Lisp has a number of limitations This pap er describ es extensions to the interface that facilitate the inclusion of C and Fortran co de into Common Lisp systems In particular these extensions make it easy to utilize libraries of numerical subroutines such as those from Numerical Recip es in C from within ACL including those routines that take functions as arguments A mechanism for creating Lisplike dynamic runtime closures for C routines is also describ ed Acknowledgments The research presented in this do cument is supp orted in part by NASA grants NCC and NAG This research is also part of the Rutgers based
    [Show full text]