DOCSLIB.ORG

ESA: a CLIM Library for Writing Emacs-Style Applications

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
ESA: a CLIM Library for Writing Emacs-Style Applications ESA: A CLIM Library for Writing Emacs-Style Applications Robert Strandh Troels Henriksen LaBRI, Université Bordeaux 1 DIKU, University of Copenhagen 351, Cours de la Libération Universitetsparken 1, Copenhagen 33405 Talence Cedex [email protected] France [email protected] David Murray Christophe Rhodes ADMurray Associates Goldsmiths, University of London 10 Rue Carrier Belleuse, 75015 Paris New Cross Road, London, SE14 6NW [email protected] [email protected] ABSTRACT style applications. The central distinguishing feature of an We describe ESA (for Emacs-Style Application), a library Emacs-style application, for our purposes, is that it uses for writing applications with an Emacs look-and-feel within short sequences of keystrokes as the default method of in- the Common Lisp Interface Manager. The ESA library voking commands, and only occasionally requires the user to takes advantage of the layered design of CLIM to provide a type the full name of the command in a minibuffer. A spe- command loop that uses Emacs-style multi-keystroke com- cial keystroke (M-x) is used to invoke commands by name. mand invocation. ESA supplies other functionality for writ- This interaction style is substantially different from the one ing such applications such as a minibuffer for invoking ex- provided by CLIM by default, and therefore required us to tended commands and for supplying command arguments, write a different CLIM top level. Fortunately, CLIM was Emacs-style keyboard macros and numeric arguments, file designed to make this not only possible but fairly straight- and buffer management, and more. ESA is currently used forward, as the implementation of a replacement top level in two major CLIM applications: the Climacs text editor can build on the protocol layers beneath, just as the default (and the Drei text gadget integrated with the McCLIM im- top level is built. plementation), and the Gsharp score editor. This paper describes the features provided by ESA, gives some detail The ESA library provides other features that are helpful in about their implementation, and suggests avenues for fur- the creation of Emacs-style applications; these features need ther work. not be used, but are available if desired. A client applica- tion may choose to use an info pane1 to display information 1. INTRODUCTION about an associated master pane, such as the name of a buffer being edited, whether application state needs saving, The Common Lisp Interface Manager (CLIM) [3] is spec- or the position of the cursor in a buffer. Other optional com- ification of a substantial library for user interaction with ponents include a protocol for file input/output with ver- Common Lisp applications. CLIM has a layered design, sioning support; a framework for reading and writing buffers and defines a fairly large collection of interacting protocols (with application-defined content) to external streams; and that together make up the full library. Thanks to this lay- support for displaying command and keystroke documenta- ered approach, it is straightforward to add functionality to tion on-demand. However, we wish to emphasize that, for CLIM by defining new classes and new methods on existing our purposes, the defining characteristic of an Emacs-style generic functions: provided that they respect the defined application is not its function (such as editing text files or protocols, such extensions will integrate seamlessly into the text buffers) but its mode of interaction. rest of CLIM. Customization of the standard behaviour of CLIM components is likewise straightforward, using stan- Two major applications already use the ESA library, namely dard CLOS means such as subclassing and auxiliary meth- Drei, the Emacs-like editor component distributed as part of ods on protocol generic functions as in [1]. For more infor- McCLIM [7] (and its extension to a standalone application, mation on CLIM, see for example [2, 4, 5]. Climacs [6]) and Gsharp, an editor for music scores. Thanks to the ESA library, the look and feel of these applications is ESA is a library for CLIM that assists in writing Emacs- similar, even though they manipulate very different objects. Other applications that use the ESA library have been writ- ten or are in the process of development, such as a directory editor, a mail client, and an info documentation browser. ESA is developed and distributed as part of McCLIM2, but 1a \mode line" in Emacs terminology. Copyright is held by the author/owner(s). 2 ILC’07, April 1–4 2007, Cambridge, UK See http://common-lisp.net/project/mcclim/ for in- ACM 978-1-59593-618-9/07/04 structions on obtaining McCLIM and ESA. has been run on other CLIM implementations in the past, marker, *numeric-argument-p*, a Boolean value that indi- and, to the authors' knowledge, it should still be possible to cates whether a numeric argument was given by the user at do so. ESA is designed as a portable layer that should run on all. This extension allows ESA applications to tell the differ- top of any CLIM implementation, using only exported CLIM ence between the case where a numeric argument of 1 was symbols, though this is unfortunately not always possible. explicitly given, and the case where no numeric argument was given. The rest of this paper gives more details about each of the components making up the ESA library: section 2 intro- Finally, the ESA top level contains support for execut- duces the customized top level and command loop; section ing Emacs-style keyboard macros, whereby a sequence of 3 discusses the support for keystroke handling using CLIM keystrokes is recorded for later playback. This mechanism command tables, and describes the command tables avail- is very hard to implement unless there is support in the able for use by client applications. Sections 4 and 5 describe top level for it, because special treatment is required for the support for multiple windows and for buffer handling, keystrokes that start and end the recording. respectively, following which we demonstrate an example Emacs-style application, and conclude with a discussion of 2.1 Command Arguments the scope for further work. The custom top-level function provided by ESA is integrated into CLIM in that it uses the CLIM function accept to 2. TOP LEVEL acquire commands and arguments. The ESA library cus- A key part of CLIM is the top level which executes a com- tomizes the stream-accept generic function called by ac- mand loop that, in each iteration, acquires a command and cept so that commands and arguments are prompted for in any arguments that the command might need, and finally the ESA minibuffer. executes the command. The minibuffer's version of stream-accept calls the stan- CLIM provides a default top level that prompts the user for dard prompt-for-accept function, but then calls accept- a command to be executed. The user can satisfy this request 1-for-minibuffer, an ESA-internal function, rather than by typing the name of a command (with completion) into an the CLIM function accept-1. We must use our own func- interactor pane; by selecting an entry in a menu; by issuing tion as we wish to turn input sensitization off, and accept-1 a gesture associated with the command; or by clicking on does not allow this. a presentation that has a presentation-to-command transla- tor associated with it. Command arguments are acquired There is additional work required to support accepting com- in a similar way. This default top level works fine when mands for the com-extended-command command (invoked gestures are mouse gestures or single keystrokes using some by M-x). ESA provides its own command-parser and partial- modifier such as control or meta, but is less well adapted command-parser to integrate well with ESA's top level; how- when commands are to be invoked by keystrokes associated ever, there is no standard way to discover, given a command with ordinary characters and when sequences of keystrokes name, what arguments that command requires, and conse- should be used, as in Emacs. quently the implementation of these command parsers are sensitive to the internal implementation details of the CLIM When the CLIM function run-frame-top-level is invoked implementation. on an application frame, CLIM executes the top-level func- tion associated with the frame. What top-level function 3. COMMAND TABLES is associated with a particular frame is determined by CLIM command tables support both nesting and inheri- the :top-level option given to the standard CLIM macro tance. Inheritance is used for code factoring as usual. An define-application-frame. When no such initarg is given, entry in a command table can be associated with a name in CLIM uses the generic function default-frame-top-level a menu or with a single keystroke, usually with some modi- as the top-level function for the frame. ESA applications fier key such as control or meta. The value of an entry can must give the :top-level option with a value of (esa-top- be either a command to be executed, or another command level) in order to use the specific top-level function pro- table for nesting. Multiple keystrokes such as required by vided as part of the ESA library. Emacs-style applications are not supported, however. The ESA top level accumulates a sequence of keystrokes The Emacs-style interaction mode assumes that the vast until that sequence is associated with a command. To de- majority of all commands are to be invoked by sequences termine whether that is the case, the top level searches a of keystrokes that may be ordinary characters, and that on hierarchy of command tables (see section 3 for the details of the rare occasion that a command is needed that is not as- this mechanism).
Load more

Recommended publications
  • Common Lispworks User Guide
    LispWorks® for the Windows® Operating System Common LispWorks User Guide Version 5.1 Copyright and Trademarks Common LispWorks User Guide (Windows version) Version 5.1 February 2008 Copyright © 2008 by LispWorks Ltd. All Rights Reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of LispWorks Ltd. The information in this publication is provided for information only, is subject to change without notice, and should not be construed as a commitment by LispWorks Ltd. LispWorks Ltd assumes no responsibility or liability for any errors or inaccuracies that may appear in this publication. The software described in this book is furnished under license and may only be used or copied in accordance with the terms of that license. LispWorks and KnowledgeWorks are registered trademarks of LispWorks Ltd. Adobe and PostScript are registered trademarks of Adobe Systems Incorporated. Other brand or product names are the registered trade- marks or trademarks of their respective holders. The code for walker.lisp and compute-combination-points is excerpted with permission from PCL, Copyright © 1985, 1986, 1987, 1988 Xerox Corporation. The XP Pretty Printer bears the following copyright notice, which applies to the parts of LispWorks derived therefrom: Copyright © 1989 by the Massachusetts Institute of Technology, Cambridge, Massachusetts. Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, pro- vided that this copyright and permission notice appear in all copies and supporting documentation, and that the name of M.I.T.
    [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]
  • Proceedings-Print.Pdf ISSN: 2175-6759 ISBN: 978-85-76694-75-5
    Edited by: Flávio Luiz Schiavoni Rodrigo Schramm José Eduardo Fornari Novo Junior Leandro Lesqueves Costalonga ISSN 2175-6759 Ficha catalográfica elaborada pelo Setor de Processamento Técnico da Divisão de Biblioteca da UFSJ Simpósio Brasileiro de Computação Musical (15. : 2015 : Campinas, SP) Anais [recurso eletrônico] do 15º Simpósio Brasileiro de Computação Musical = 15th Brazilian Symposium on Computer Music (SBCM), 23 a 25 de novembro de 2015, Campinas, SP / editado por Flávio Luiz Schiavoni ... [et al.]. – Campinas: UNICAMP, 2015. Disponível em: http://compmus.ime.usp.br/sbcm2015/files/proceedings-print.pdf ISSN: 2175-6759 ISBN: 978-85-76694-75-5 1. Música por computador. 2. Arte e tecnologia. 3. Multimídia (Arte). I. Schiavoni, Flávio Luiz (Ed.). II. Título. CDU: 78:004 SBCM 2015 is organized by University of Campinas (UNICAMP) President: Jos´eTadeu Jorge Vice President for University Coordination: Alvaro´ Penteado Cr´osta Vice President for Research (PRP): Gl´aucia Maria Pastore Coordination of Interdisciplinary Centers (COCEN) Coordinator: Jurandir Zullo Junior Interdisciplinary Center for Studies on Sound Communication (NICS) Coordinator: Adriana do Nascimento Ara´ujo Mendes Art Institute, Department of Music Director: Fernando Augusto de Almeida Hashimoto Chief of the Department: Leandro Barsalini Coordinator of Graduate Studies in Music: Alexandre Zamith Almeida Coordinator of Undergraduate Studies in Music: Paulo J. Siqueira Tin´e Production Center Staff (Ceprod) Visual programming: Ivan Avelar Promotion Brazilian Computer
    [Show full text]
  • Connecting Time and Timbre Computational Methods for Generative Rhythmic Loops Insymbolic and Signal Domainspdfauthor
    Connecting Time and Timbre: Computational Methods for Generative Rhythmic Loops in Symbolic and Signal Domains Cárthach Ó Nuanáin TESI DOCTORAL UPF / 2017 Thesis Director: Dr. Sergi Jordà Music Technology Group Dept. of Information and Communication Technologies Universitat Pompeu Fabra, Barcelona, Spain Dissertation submitted to the Department of Information and Communication Tech- nologies of Universitat Pompeu Fabra in partial fulfillment of the requirements for the degree of DOCTOR PER LA UNIVERSITAT POMPEU FABRA Copyright c 2017 by Cárthach Ó Nuanáin Licensed under Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 Music Technology Group (http://mtg.upf.edu), Department of Information and Communication Tech- nologies (http://www.upf.edu/dtic), Universitat Pompeu Fabra (http://www.upf.edu), Barcelona, Spain. III Do mo mháthair, Marian. V This thesis was conducted carried out at the Music Technology Group (MTG) of Universitat Pompeu Fabra in Barcelona, Spain, from Oct. 2013 to Nov. 2017. It was supervised by Dr. Sergi Jordà and Mr. Perfecto Herrera. Work in several parts of this thesis was carried out in collaboration with the GiantSteps team at the Music Technology Group in UPF as well as other members of the project consortium. Our work has been gratefully supported by the Department of Information and Com- munication Technologies (DTIC) PhD fellowship (2013-17), Universitat Pompeu Fabra, and the European Research Council under the European Union’s Seventh Framework Program, as part of the GiantSteps project ((FP7-ICT-2013-10 Grant agreement no. 610591). Acknowledgments First and foremost I wish to thank my advisors and mentors Sergi Jordà and Perfecto Herrera. Thanks to Sergi for meeting me in Belfast many moons ago and bringing me to Barcelona.
    [Show full text]
  • ESA: a CLIM Library for Writing Emacs-Style Applications
    ESA: A CLIM Library for Writing Emacs-Style Applications Robert Strandh Troels Henriksen LaBRI, Université Bordeaux 1 DIKU, University of Copenhagen 351, Cours de la Libération Universitetsparken 1, Copenhagen 33405 Talence Cedex [email protected] France [email protected] David Murray Christophe Rhodes ADMurray Associates Goldsmiths, University of London 10 Rue Carrier Belleuse, 75015 Paris New Cross Road, London, SE14 6NW [email protected] [email protected] ABSTRACT style applications. The central distinguishing feature of an We describe ESA (for Emacs-Style Application), a library Emacs-style application, for our purposes, is that it uses for writing applications with an Emacs look-and-feel within short sequences of keystrokes as the default method of in- the Common Lisp Interface Manager. The ESA library voking commands, and only occasionally requires the user to takes advantage of the layered design of CLIM to provide a type the full name of the command in a minibuffer. A spe- command loop that uses Emacs-style multi-keystroke com- cial keystroke (M-x) is used to invoke commands by name. mand invocation. ESA supplies other functionality for writ- This interaction style is substantially different from the one ing such applications such as a minibuffer for invoking ex- provided by CLIM by default, and therefore required us to tended commands and for supplying command arguments, write a different CLIM top level. Fortunately, CLIM was Emacs-style keyboard macros and numeric arguments, file designed to make this not only possible but fairly straight- and buffer management, and more. ESA is currently used forward, as the implementation of a replacement top level in two major CLIM applications: the Climacs text editor can build on the protocol layers beneath, just as the default (and the Drei text gadget integrated with the McCLIM im- top level is built.
    [Show full text]
  • A Python Implementation for Racket
    PyonR: A Python Implementation for Racket Pedro Alexandre Henriques Palma Ramos Thesis to obtain the Master of Science Degree in Information Systems and Computer Engineering Supervisor: António Paulo Teles de Menezes Correia Leitão Examination Committee Chairperson: Prof. Dr. José Manuel da Costa Alves Marques Supervisor: Prof. Dr. António Paulo Teles de Menezes Correia Leitão Member of the Committee: Prof. Dr. João Coelho Garcia October 2014 ii Agradecimentos Agradec¸o... Em primeiro lugar ao Prof. Antonio´ Leitao,˜ por me ter dado a oportunidade de participar no projecto Rosetta com esta tese de mestrado, por todos os sabios´ conselhos e pelos momentos de discussao˜ e elucidac¸ao˜ que se proporcionaram ao longo deste trabalho. Aos meus pais excepcionais e a` minha mana preferida, por me terem aturado e suportado ao longo destes quase 23 anos e sobretudo pelo incondicional apoio durante estes 5 anos de formac¸ao˜ superior. Ao pessoal do Grupo de Arquitectura e Computac¸ao˜ (Hugo Correia, Sara Proenc¸a, Francisco Freire, Pedro Alfaiate, Bruno Ferreira, Guilherme Ferreira, Inesˆ Caetano e Carmo Cardoso), por todas as sug- estoes˜ e pelo inestimavel´ feedback em artigos e apresentac¸oes.˜ Aos amigos em Tomar (Rodrigo Carrao,˜ Hugo Matos, Andre´ Marques e Rui Santos) e em Lisboa (Diogo da Silva, Nuno Silva, Pedro Engana, Kaguedes, Clara Paiva e Odemira), por terem estado pre- sentes, duma forma ou doutra, nos essenciais momentos de lazer. A` Fundac¸ao˜ para a Cienciaˆ e Tecnologia (FCT) e ao INESC-ID pelo financiamento e acolhimento atraves´ da atribuic¸ao˜ de uma bolsa de investigac¸ao˜ no ambitoˆ dos contratos Pest-OE/EEI/LA0021/2013 e PTDC/ATP-AQI/5224/2012.
    [Show full text]
  • ASDF 3, Or Why Lisp Is Now an Acceptable Scripting Language (Extended Version)
    ASDF 3, or Why Lisp is Now an Acceptable Scripting Language (Extended version) François-René Rideau Google [email protected] Abstract libraries, or network services; one can scale them into large, main- ASDF, the de facto standard build system for Common Lisp, has tainable and modular systems; and one can make those new ser- been vastly improved between 2009 and 2014. These and other im- vices available to other programs via the command-line as well as provements finally bring Common Lisp up to par with "scripting via network protocols, etc. languages" in terms of ease of writing and deploying portable code The last barrier to making that possible was the lack of a that can access and "glue" together functionality from the underly- portable way to build and deploy code so a same script can run ing system or external programs. "Scripts" can thus be written in unmodified for many users on one or many machines using one or Common Lisp, and take advantage of its expressive power, well- many different compilers. This was solved by ASDF 3. defined semantics, and efficient implementations. We describe the ASDF has been the de facto standard build system for portable most salient improvements in ASDF and how they enable previ- CL software since shortly after its release by Dan Barlow in 2002 ously difficult and portably impossible uses of the programming (Barlow 2004). The purpose of a build system is to enable divi- language. We discuss past and future challenges in improving this sion of labor in software development: source code is organized key piece of software infrastructure, and what approaches did or in separately-developed components that depend on other compo- didn’t work in bringing change to the Common Lisp community.
    [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]
  • Signal Processing for Music Analysis Meinard Müller, Member, IEEE, Daniel P
    IEEE JOURNAL OF SELECTED TOPICS IN SIGNAL PROCESSING, VOL. 0, NO. 0, 2011 1 Signal Processing for Music Analysis Meinard Müller, Member, IEEE, Daniel P. W. Ellis, Senior Member, IEEE, Anssi Klapuri, Member, IEEE, and Gaël Richard, Senior Member, IEEE Abstract—Music signal processing may appear to be the junior consumption, which is not even to mention their vital role in relation of the large and mature field of speech signal processing, much of today’s music production. not least because many techniques and representations originally This paper concerns the application of signal processing tech- developed for speech have been applied to music, often with good niques to music signals, in particular to the problems of ana- results. However, music signals possess specific acoustic and struc- tural characteristics that distinguish them from spoken language lyzing an existing music signal (such as piece in a collection) to or other nonmusical signals. This paper provides an overview of extract a wide variety of information and descriptions that may some signal analysis techniques that specifically address musical be important for different kinds of applications. We argue that dimensions such as melody, harmony, rhythm, and timbre. We will there is a distinct body of techniques and representations that examine how particular characteristics of music signals impact and are molded by the particular properties of music audio—such as determine these techniques, and we highlight a number of novel music analysis and retrieval tasks that such processing makes pos- the pre-eminence of distinct fundamental periodicities (pitches), sible. Our goal is to demonstrate that, to be successful, music audio the preponderance of overlapping sound sources in musical en- signal processing techniques must be informed by a deep and thor- sembles (polyphony), the variety of source characteristics (tim- ough insight into the nature of music itself.
    [Show full text]
  • How to Make Lisp Go Faster Than C [Pdf]
    IAENG International Journal of Computer Science, 32:4, IJCS_32_4_19 ______________________________________________________________________________________ How to make Lisp go faster than C Didier Verna∗ Abstract statically (hence known at compile-time), just as you would do in C. Contrary to popular belief, Lisp code can be very ef- cient today: it can run as fast as equivalent C code Safety Levels While dynamically typed Lisp code or even faster in some cases. In this paper, we explain leads to dynamic type checking at run-time, it how to tune Lisp code for performance by introducing is possible to instruct the compilers to bypass the proper type declarations, using the appropriate all safety checks in order to get optimum per- data structures and compiler information. We also formance. explain how eciency is achieved by the compilers. These techniques are applied to simple image process- Data Structures While Lisp is mainly known for ing algorithms in order to demonstrate the announced its basement on list processing, the Common- performance on pixel access and arithmetic operations Lisp standard features very ecient data types in both languages. such as specialized arrays, structs or hash tables, making lists almost completely obsolete. Keywords: Lisp, C, Numerical Calculus, Image Pro- cessing, Performance Experiments on the performance of Lisp and C were conducted in the eld of image processing. We bench- 1 Introduction marked, in both languages, 4 simple algorithms to measure the performances of the fundamental low- More than 15 years after the standardization process level operations: massive pixel access and arithmetic of Common-Lisp [5], and more than 10 years after processing.
    [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]