DOCSLIB.ORG

7 European Lisp Symposium

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
7 European Lisp Symposium Proceedings of ELS 2014 7th European Lisp Symposium May 5 – 6 2014 IRCAM, Paris, France ISSN: 2677-3465 Preface Message from the Programme Chair Greetings, members of the Lisp Community. We are a diverse community. Some have been programming in Lisp for some time, some are just starting out, and some are even just peering in curiously from outside—including, in some cases, family and friends. A variety of dialects are represented as well: Common Lisp, Racket, Clojure and Emacs Lisp to name a few about which we have papers. But we’ve invited attendance from Scheme, AutoLisp, ISLISP, Dylan, ACL2, ECMAScript, SKILL, and Hop. Even then, I’m sure to have left some out. The important thing is that these are all Lisp. In the work I did with language stands, I recall John McCarthy specifically asking that ANSI and the ISO not name their work product anything that appeared to claim the whole of the name Lisp. He wanted to reserve that for the family of languages, which he felt should continue to freely evolve and add new members. This gathering honors that spirit by inviting that whole extended family. So, to all of this diverse community: Welcome! We’re all from different backgrounds, but each brings something to contribute in terms of ex- perience, interest, or enthusiasm. We are different, but today we’re also all equals, here to exchange ideas and energy. In that spirit, please make sure to visit not just with old friends but also with those you have not met, making them feel that sense of welcome so they’ll have reason to return and you’ll have even more old friends the next time. Or, if you’re new, please don’t be shy: Step up and introduce yourself to any among us even if we’ve slipped and forgotten to reach out to you. Also, please find a time during the conference to thank Didier Verna and Gérard Assayag for acting as Local Chairs, and to thank members of the program committee for working on a very tight time schedule to select the papers and provide excellent quality feedback to authors. Thanks are also due to IRCAM, which has provided our intellectually stimulating venue as well as practical logistical support. And, of course, the backbone of the conference is the ac- tual content, so make sure to tell the invited speakers, the paper presenters, those performing demonstrations, and those who offer lightning talks that their presence has made a difference. As you can probably see, a lot goes into preparing a conference like this, and no one’s getting rich off of it —– at least not in money. But your stated appreciation will go a long way toward making the effort of all of these people seem worthwhile. Thanks also to you for attending. This conference would be nothing without attendees. I hope you have a great time. Kent Pitman ELS 2014 iii Message from the Local Chair Welcome to Paris! ELS 2014 is undoubtedly one of the most successful events in the European Lisp Symposium series, with almost 80 delegates from nearly 20 countries, including quite distant ones such as Japan, India and the United States of America. More than just “European”, ELS is now indeed fully international. It is great to see such a crowd gathering in Paris, and I hope you will have a great time meet- ing fellow lispers from all over the world, visiting the “Lambda Tower” and all the touristic wonders Paris has to offer. As a part-time researcher, part-time musician, I need to stress that holding the symposium at IRCAM is also a very special pleasure for me. IRCAM is an amazing place for music research and also a nest of hard-core lispers. We couldn’t have hoped for a better place. In that regard, I am deeply grateful to my co-local chair, Gérard Assayag, without whom this would simply not have been possible. In order to organize an event like this one, many other people work in the shadows, although shadows are crucial to make ELS a bright event. I need to extend my warmest thanks to Daniela Becker and Sylvie Benoît, who took care of a lot of things. Like every year, our sponsors also are of a tremendous importance, so thank you, EPITA, CNRS, UPMC, LispWorks, and Franz! Finally, and this time, not as a local chair but as the president of the European Lisp Sympo- sium’s steering committee, I wish to express my deepest gratitude to Kent Pitman, who ac- cepted the role of programme chair this year, perhaps not knowing exactly what he was getting into. From where I stand, working with Kent has been a very smooth experience, one that I would redo anytime. Let us now hope that you will have as much fun attending the symposium that we had orga- nizing it. In just one sexp. (have :fun #n!) Organization Programme Chair • Kent M. Pitman, Hypermeta Inc., USA Local Chairs • Didier Verna, EPITA/LRDE, Paris, France • Gérard Assayag, IRCAM, UMR STMS (CNRS, UPMC), France Programme Committee • Marie Beurton-Aimar, LaBRI, University of Bordeaux, France • Pierre Parquier, IBM France Lab, Paris, France • Rainer Joswig, Hamburg, Germany • Guiseppe Attardi, Università di Pisa, Italy • Taiichi Yuasa, Kyoto University, Japan • António Leitão, IST/Universidade de Lisboa, Portugal • Christophe Rhodes, Goldsmiths, University of London, UK • Olin Shivers, Northeastern University, USA • Charlotte Herzeel, IMEC, ExaScience Life Lab, Leuven, Belgium Organizing Committee • Daniela Becker, EPITA/LRDE, Paris, France • Sylvie Benoit, IRCAM, Paris, France ELS 2014 v Sponsors EPITA 14-16 rue Voltaire FR-94276 Le Kremlin-Bicêtre CEDEX France www.epita.fr IRCAM UMR STMS (CNRS, UPMC) Institut de Recherche et Coordination Acoustique / Musique 1, place Igor-Stravinsky 75004 Paris France www.ircam.fr LispWorks Ltd. St John’s Innovation Centre Cowley Road Cambridge CB4 0WS England www.lispworks.com Franz Inc. 2201 Broadway, Suite 715 Oakland, CA 94612 www.franz.com vi ELS 2014 Contents Preface iii Message from the Programme Chair . iii Message from the Local Chair . iv Organization v Programme Chair . .v Local Chairs . .v Programme Committee . .v Organizing Committee . .v Sponsors . vi Invited Talks 1 Making Creativity: Software as Creative Partner – Richard P. Gabriel ...........1 Parallel Programming with Lisp, for Performance – Pascal Costanza ...........2 Sending Beams into the Parallel Cube – Gábor Melis ....................2 Session I: Language and Libraries 3 CLAUDE: The Common Lisp Library Audience Expansion Toolkit – Nick Levine ....4 ASDF3, or Why Lisp is Now an Acceptable Scripting Language – François-René Rideau 12 Generalizers: New Metaobjects for Generalized Dispatch – Christophe Rhodes, Jan Morin- gen and David Lichteblau .................................. 20 Session II: Demonstrations 29 web-mode.el: Heterogeneous Recursive Code Parsing with Emacs Lisp – François- Xavier Bois ......................................... 30 The OMAS Multi-Agent Platform – Jean-Paul Barthès .................... 33 Yet Another Wiki – Alain Marty ................................ 35 Session III: Application and Deployment Issues 37 High performance Concurrency in Common Lisp: Hybrid Transactional Memory with STMX – Massimiliano Ghilardi .............................. 38 A Functional Approach for Disruptive Event Discovery and Policy Monitoring in Mo- bility Scenarios – Ignasi Gómez-Sebastià, Luis Oliva, Sergio Alvarez-Napagao, Dario Garcia-Gasulla, Arturo Tejeda and Javier Vazquez ..................... 46 A Racket-Based Robot to Teach First-Year Computer Science – Franco Raimondi, Giuseppe Primiero, Kelly Androutsopoulos, Nikos Gorogiannis, Martin Loomes, Michael Margo- lis, Puja Varsani, Nick Weldin and Alex Zivanovic .................... 54 Session IV: Crossing the Language Barrier 63 A need for Multilingual Names – Jean-Paul Barthès ..................... 64 An Implementation of Python for Racket – Pedro Ramos and António Leitão ....... 72 Defmacro for C: Lightweight, Ad Hoc Code Generation – Kai Selgrad, Alexander Lier, Markus Wittmann, Daniel Lohmann and Marc Stamminger ............... 80 ELS 2014 vii Invited Talks Making Creativity: Software as Creative Partner Richard P.Gabriel, IBM, Redwood City, CA, USA Programming, software development, and software engineering: We are taught to solve puzzles and do what we’re told. We carry these lessons into our jobs and careers without deliberation. Old fashioned software engineering aims to make no mistakes; agile aims to render program- mers compliant, and commands them make money for their bosses. For the past year I’ve been exploring what creativity means during the act of writing, and I’ve been doing it by construct- ing a software partner that acts as a scientific engine of discovery –— a partner that displays a flair for the strange that even the most daring poets can rarely match. I don’t have require- ments, I don’t have specifications, and I normally don’t have a plan much beyond a guess. If my program doesn’t surprise me, I cry “failure!” and lament. I’ll explore what programming is, how software can act as a collaborator, show you how the agile practices are like training wheels, and explain how a program can astound. All in Lisp, of course. Richard P. “Dick” Gabriel overcame a hardscrabble, working-class upbringing in the dreadfully indus- trialized and famously polluted Merrimack Valley of eastern Massachusetts to become one of the few genuine Renaissance men to emerge from the OO milieu: scholar, scientist, poet, performance artist, entrepreneur, musician, essayist, and yes, hacker. Though somewhat less well-endowed of the effortless intellectual incandescence, easy charisma, and raw animal magnetism of so many of his generation of future object-oriented luminaries, he was able, with discipline, determination, and hard work, to survive the grueling demands of elite, first-tier academic institutions such as MIT, Stanford and UIUC to earn his PhD and become a leader among the burgeoning legions of Lisp-dom during the early nineties. However, after a series of the inevitable, endemic startup setbacks that the Internet boom all too often left in its wake, Gabriel grew weary of the cold, cloistered, celibate tedium of engineering culture, and fell willing prey to the lure of the exotic social and intellectual stimulation and blandishments that only the Liberal Arts could offer.
Load more

Recommended publications
  • Javascript and the DOM
    Javascript and the DOM 1 Introduzione alla programmazione web – Marco Ronchetti 2020 – Università di Trento The web architecture with smart browser The web programmer also writes Programs which run on the browser. Which language? Javascript! HTTP Get + params File System Smart browser Server httpd Cgi-bin Internet Query SQL Client process DB Data Evolution 3: execute code also on client! (How ?) Javascript and the DOM 1- Adding dynamic behaviour to HTML 3 Introduzione alla programmazione web – Marco Ronchetti 2020 – Università di Trento Example 1: onmouseover, onmouseout <!DOCTYPE html> <html> <head> <title>Dynamic behaviour</title> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> </head> <body> <div onmouseover="this.style.color = 'red'" onmouseout="this.style.color = 'green'"> I can change my colour!</div> </body> </html> JAVASCRIPT The dynamic behaviour is on the client side! (The file can be loaded locally) <body> <div Example 2: onmouseover, onmouseout onmouseover="this.style.background='orange'; this.style.color = 'blue';" onmouseout=" this.innerText='and my text and position too!'; this.style.position='absolute'; this.style.left='100px’; this.style.top='150px'; this.style.borderStyle='ridge'; this.style.borderColor='blue'; this.style.fontSize='24pt';"> I can change my colour... </div> </body > JavaScript is event-based UiEvents: These event objects iherits the properties of the UiEvent: • The FocusEvent • The InputEvent • The KeyboardEvent • The MouseEvent • The TouchEvent • The WheelEvent See https://www.w3schools.com/jsref/obj_uievent.asp Test and Gym JAVASCRIPT HTML HEAD HTML BODY CSS https://www.jdoodle.com/html-css-javascript-online-editor/ Javascript and the DOM 2- Introduction to the language 8 Introduzione alla programmazione web – Marco Ronchetti 2020 – Università di Trento JavaScript History • JavaScript was born as Mocha, then “LiveScript” at the beginning of the 94’s.
    [Show full text]
  • An Implementation of Python for Racket
    An Implementation of Python for Racket Pedro Palma Ramos António Menezes Leitão INESC-ID, Instituto Superior Técnico, INESC-ID, Instituto Superior Técnico, Universidade de Lisboa Universidade de Lisboa Rua Alves Redol 9 Rua Alves Redol 9 Lisboa, Portugal Lisboa, Portugal [email protected] [email protected] ABSTRACT Keywords Racket is a descendent of Scheme that is widely used as a Python; Racket; Language implementations; Compilers first language for teaching computer science. To this end, Racket provides DrRacket, a simple but pedagogic IDE. On the other hand, Python is becoming increasingly popular 1. INTRODUCTION in a variety of areas, most notably among novice program- The Racket programming language is a descendent of Scheme, mers. This paper presents an implementation of Python a language that is well-known for its use in introductory for Racket which allows programmers to use DrRacket with programming courses. Racket comes with DrRacket, a ped- Python code, as well as adding Python support for other Dr- agogic IDE [2], used in many schools around the world, as Racket based tools. Our implementation also allows Racket it provides a simple and straightforward interface aimed at programs to take advantage of Python libraries, thus signif- inexperienced programmers. Racket provides different lan- icantly enlarging the number of usable libraries in Racket. guage levels, each one supporting more advanced features, that are used in different phases of the courses, allowing Our proposed solution involves compiling Python code into students to benefit from a smoother learning curve. Fur- semantically equivalent Racket source code. For the run- thermore, Racket and DrRacket support the development of time implementation, we present two different strategies: additional programming languages [13].
    [Show full text]
  • MELT a Translated Domain Specific Language Embedded in the GCC
    MELT a Translated Domain Specific Language Embedded in the GCC Compiler Basile STARYNKEVITCH CEA, LIST Software Safety Laboratory, boˆıte courrier 94, 91191 GIF/YVETTE CEDEX, France [email protected] [email protected] The GCC free compiler is a very large software, compiling source in several languages for many targets on various systems. It can be extended by plugins, which may take advantage of its power to provide extra specific functionality (warnings, optimizations, source refactoring or navigation) by processing various GCC internal representations (Gimple, Tree, ...). Writing plugins in C is a complex and time-consuming task, but customizing GCC by using an existing scripting language inside is impractical. We describe MELT, a specific Lisp-like DSL which fits well into existing GCC technology and offers high-level features (functional, object or reflexive programming, pattern matching). MELT is translated to C fitted for GCC internals and provides various features to facilitate this. This work shows that even huge, legacy, software can be a posteriori extended by specifically tailored and translated high-level DSLs. 1 Introduction GCC1 is an industrial-strength free compiler for many source languages (C, C++, Ada, Objective C, Fortran, Go, ...), targetting about 30 different machine architectures, and supported on many operating systems. Its source code size is huge (4.296MLOC2 for GCC 4.6.0), heterogenous, and still increasing by 6% annually 3. It has no single main architect and hundreds of (mostly full-time) contributors, who follow strict social rules 4. 1.1 The powerful GCC legacy The several GCC [8] front-ends (parsing C, C++, Go .
    [Show full text]
  • The Machine That Builds Itself: How the Strengths of Lisp Family
    Khomtchouk et al. OPINION NOTE The Machine that Builds Itself: How the Strengths of Lisp Family Languages Facilitate Building Complex and Flexible Bioinformatic Models Bohdan B. Khomtchouk1*, Edmund Weitz2 and Claes Wahlestedt1 *Correspondence: [email protected] Abstract 1Center for Therapeutic Innovation and Department of We address the need for expanding the presence of the Lisp family of Psychiatry and Behavioral programming languages in bioinformatics and computational biology research. Sciences, University of Miami Languages of this family, like Common Lisp, Scheme, or Clojure, facilitate the Miller School of Medicine, 1120 NW 14th ST, Miami, FL, USA creation of powerful and flexible software models that are required for complex 33136 and rapidly evolving domains like biology. We will point out several important key Full list of author information is features that distinguish languages of the Lisp family from other programming available at the end of the article languages and we will explain how these features can aid researchers in becoming more productive and creating better code. We will also show how these features make these languages ideal tools for artificial intelligence and machine learning applications. We will specifically stress the advantages of domain-specific languages (DSL): languages which are specialized to a particular area and thus not only facilitate easier research problem formulation, but also aid in the establishment of standards and best programming practices as applied to the specific research field at hand. DSLs are particularly easy to build in Common Lisp, the most comprehensive Lisp dialect, which is commonly referred to as the “programmable programming language.” We are convinced that Lisp grants programmers unprecedented power to build increasingly sophisticated artificial intelligence systems that may ultimately transform machine learning and AI research in bioinformatics and computational biology.
    [Show full text]
  • App Development Courses/Certificate Mississippi Curriculum Framework
    App Development Courses/Certificate Mississippi Curriculum Framework Apple/Swift Same CIP as IST 11.0201 Computer Programming/ Programmer, General Same CIP as IST 11.0202 Computer Programming, Specific Applications. July 2019 Published by: Mississippi Community College Board Division of Workforce, Career, and Technical Education 3825 Ridgewood Road Jackson, MS 39211 Phone: 601‐432‐6155 Email: [email protected] 1 FACULTY WRITING TEAM MEMBERS Brandon Sesser, East Mississippi Community College David Rose, Hinds Community College Roderick Kwan, Hinds Community College Kathy Boyte, Hinds Community College Kenneth Boyte, Hinds Community College Cody Robertson, Jones County Junior College Robin Hayes, Mississippi Gulf Coast Community College Dr. James Gruich, Mississippi Gulf Coast Community College Natasha Lewis, Northeast Mississippi Community College Nick Jackson, Northeast Mississippi Community College Tony Bouthwell, Meridian Community College Daniel Ethridge, Meridian Community College ADMINISTRATOR WRITING TEAM MEMBERS Joe Cook, Assistant Dean, East Mississippi Community College Dr. Richie McAlister, Vice President, Meridian Community College Lori Smith, Coordinator, Meridian Community College Joseph Knight, Dean, Business Development, Meridian Community College Sherry Franklin, Associate Vice President, Hinds Community College Rod Tolbert, Dean, Jones County Junior College Jason Mattox, Associate Vice President Northeast Mississippi Community College John Shows, Associate Vice President, Mississippi Gulf Coast Community College Dr.
    [Show full text]
  • Bringing GNU Emacs to Native Code
    Bringing GNU Emacs to Native Code Andrea Corallo Luca Nassi Nicola Manca [email protected] [email protected] [email protected] CNR-SPIN Genoa, Italy ABSTRACT such a long-standing project. Although this makes it didactic, some Emacs Lisp (Elisp) is the Lisp dialect used by the Emacs text editor limitations prevent the current implementation of Emacs Lisp to family. GNU Emacs can currently execute Elisp code either inter- be appealing for broader use. In this context, performance issues preted or byte-interpreted after it has been compiled to byte-code. represent the main bottleneck, which can be broken down in three In this work we discuss the implementation of an optimizing com- main sub-problems: piler approach for Elisp targeting native code. The native compiler • lack of true multi-threading support, employs the byte-compiler’s internal representation as input and • garbage collection speed, exploits libgccjit to achieve code generation using the GNU Com- • code execution speed. piler Collection (GCC) infrastructure. Generated executables are From now on we will focus on the last of these issues, which con- stored as binary files and can be loaded and unloaded dynamically. stitutes the topic of this work. Most of the functionality of the compiler is written in Elisp itself, The current implementation traditionally approaches the prob- including several optimization passes, paired with a C back-end lem of code execution speed in two ways: to interface with the GNU Emacs core and libgccjit. Though still a work in progress, our implementation is able to bootstrap a func- • Implementing a large number of performance-sensitive prim- tional Emacs and compile all lexically scoped Elisp files, including itive functions (also known as subr) in C.
    [Show full text]
  • The Elinks Manual the Elinks Manual Table of Contents Preface
    The ELinks Manual The ELinks Manual Table of Contents Preface.......................................................................................................................................................ix 1. Getting ELinks up and running...........................................................................................................1 1.1. Building and Installing ELinks...................................................................................................1 1.2. Requirements..............................................................................................................................1 1.3. Recommended Libraries and Programs......................................................................................1 1.4. Further reading............................................................................................................................2 1.5. Tips to obtain a very small static elinks binary...........................................................................2 1.6. ECMAScript support?!...............................................................................................................4 1.6.1. Ok, so how to get the ECMAScript support working?...................................................4 1.6.2. The ECMAScript support is buggy! Shall I blame Mozilla people?..............................6 1.6.3. Now, I would still like NJS or a new JS engine from scratch. .....................................6 1.7. Feature configuration file (features.conf).............................................................................7
    [Show full text]
  • 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]
  • Omnipresent and Low-Overhead Application Debugging
    Omnipresent and low-overhead application debugging Robert Strandh [email protected] LaBRI, University of Bordeaux Talence, France ABSTRACT application programmers as opposed to system programmers. The state of the art in application debugging in free Common The difference, in the context of this paper, is that the tech- Lisp implementations leaves much to be desired. In many niques that we suggest are not adapted to debugging the cases, only a backtrace inspector is provided, allowing the system itself, such as the compiler. Instead, throughout this application programmer to examine the control stack when paper, we assume that, as far as the application programmer an unhandled error is signaled. Most such implementations do is concerned, the semantics of the code generated by the not allow the programmer to set breakpoints (unconditional compiler corresponds to that of the source code. or conditional), nor to step the program after it has stopped. In this paper, we are mainly concerned with Common Furthermore, even debugging tools such as tracing or man- Lisp [1] implementations distributed as so-called FLOSS, i.e., ually calling break are typically very limited in that they do \Free, Libre, and Open Source Software". While some such not allow the programmer to trace or break in important sys- implementations are excellent in terms of the quality of the tem functions such as make-instance or shared-initialize, code that the compiler generates, most leave much to be simply because these tools impact all callers, including those desired when it comes to debugging tools available to the of the system itself, such as the compiler.
    [Show full text]
  • An Evaluation of Go and Clojure
    An evaluation of Go and Clojure A thesis submitted in partial satisfaction of the requirements for the degree Bachelors of Science in Computer Science Fall 2010 Robert Stimpfling Department of Computer Science University of Colorado, Boulder Advisor: Kenneth M. Anderson, PhD Department of Computer Science University of Colorado, Boulder 1. Introduction Concurrent programming languages are not new, but they have been getting a lot of attention more recently due to their potential with multiple processors. Processors have gone from growing exponentially in terms of speed, to growing in terms of quantity. This means processes that are completely serial in execution will soon be seeing a plateau in performance gains since they can only rely on one processor. A popular approach to using these extra processors is to make programs multi-threaded. The threads can execute in parallel and use shared memory to speed up execution times. These multithreaded processes can significantly speed up performance, as long as the number of dependencies remains low. Amdahl‘s law states that these performance gains can only be relative to the amount of processing that can be parallelized [1]. However, the performance gains are significant enough to be looked into. These gains not only come from the processing being divvied up into sections that run in parallel, but from the inherent gains from sharing memory and data structures. Passing new threads a copy of a data structure can be demanding on the processor because it requires the processor to delve into memory and make an exact copy in a new location in memory. Indeed some studies have shown that the problem with optimizing concurrent threads is not in utilizing the processors optimally, but in the need for technical improvements in memory performance [2].
    [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]