DOCSLIB.ORG

9 European Lisp Symposium

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Proceedings of the 9th European Lisp Symposium AGH University of Science and Technology, Kraków, Poland May 9 – 10, 2016 Irène Durand (ed.) ISBN-13: 978-2-9557474-0-7 ISSN: 2677-3465 Contents Preface v Message from the Programme Chair . vii Message from the Organizing Chair . viii Organization ix Programme Chair . xi Local Chair . xi Programme Committee . xi Organizing Committee . xi Sponsors . xii Invited Contributions xiii Program Proving with Coq – Pierre Castéran .........................1 Julia: to Lisp or Not to Lisp? – Stefan Karpinski .......................1 Lexical Closures and Complexity – Francis Sergeraert ...................2 Session I: Language design3 Refactoring Dynamic Languages Rafael Reia and António Menezes Leitão ..........................5 Type-Checking of Heterogeneous Sequences in Common Lisp Jim E. Newton, Akim Demaille and Didier Verna ..................... 13 A CLOS Protocol for Editor Buffers Robert Strandh ....................................... 21 Session II: Domain Specific Languages 29 Using Lisp Macro-Facilities for Transferable Statistical Tests Kay Hamacher ....................................... 31 A High-Performance Image Processing DSL for Heterogeneous Architectures Kai Selgrad, Alexander Lier, Jan Dörntlein, Oliver Reiche and Marc Stamminger .... 39 Session III: Implementation 47 A modern implementation of the LOOP macro Robert Strandh ....................................... 49 Source-to-Source Compilation via Submodules Tero Hasu and Matthew Flatt ............................... 57 Extending Software Transactional Memory in Clojure with Side-Effects and Transac- tion Control Søren Kejser Jensen and Lone Leth Thomsen ........................ 65 Session IV: Applications 73 CANDO: A Compiled Programming Language for Computer-Aided Nanomaterial Design and Optimization Based on Clasp Common Lisp Christian E. Schafmeister .................................. 75 iii A Case Study in Implementation-Space Exploration Alexander Lier, Linus Franke, Marc Stamminger and Kai Selgrad ............ 83 Demonstrations 91 Accessing local variables during debugging Michael Raskin and Nikita Mamardashvili ........................ 93 Building Common Lisp programs using Bazel James Y. Knight, François-René Rideau and Andrzej Walczak .............. 95 Fast Interactive Functional Computer Vision with Racket Benjamin Seppke and Leonie Dreschler–Fischer ...................... 97 An Inferred System Description James Anderson ....................................... 99 Distributed High Performance Computing in Common Lisp Marco Heisig and Nicolas Neuss .............................. 101 iv ELS 2016 Preface Message from the Programme Chair Welcome to the 9thth edition of the European Lisp Symposium! From language implementation to applications through systems tools, language extensions and Domain Specific Languages, we have a great variety of contributions. Many dialects of the Lisp family are represented as well – Common Lisp, Racket, Clojure and Julia – showing the diversity of the community. I thank the program committee members for their relevant reviews, their responsiveness and timeliness. I thank the steering commitee of ELS for entrusting me this task of which I had no previous experience. I thank Michał Psota for giving life to these contributions in organizing the conference in Kraków. Many thanks to Didier Verna who assisted me all along the process, taking care of distributing calls and helping me whether for practical matters or for scientific decisions. Finally, thanks to the authors, to all those that submitted contributions, and to the participants for keeping the community alive. I hope you have a great time. Irène Durand, Bordeaux, May 2016 ELS 2016 vii Message from the Organizing Chair Welcome to Kraków! Kraków is one of the oldest cities in Poland, the place where many of the Polish kings lived and ruled, this was the capital city until the 18th century. According to an old legend the city was built by ’Krakus’ above a cave occupied by a Dragon. The city is one of the leading centers of Polish academic, cultural, and artistic life. Today one can discover many attractions here – walking around the main market square, shopping at the old Cloth Hall, admiring the Wawel Castle – the residence of Polish Kings, listening to the famous trumpet signal from the top of St. Mary’s Basilica that’s being transmitted throughout Poland every day at noon through the national radio. The AGH University of Science and Technology which is hosting us now, was established in 1919 as the University of Mining and Metallurgy. Today it is a respectable University with well-qualified staff, doing innovative research. I am really glad so many people have registered and come to Poland to listen about the Lisp language family. I hope you will have good time not only at the lecture room, but also outside wandering around the city. It would be really hard to organize a symposium without help. I would like to thank Didier Verna, his experience and patience to guide me through the process was invaluable (This is the first symposium I’m helping organizing). I would like to also thank "BIT" – a students’ scientific association which is hosting us together with the Department of Computer Science. Last but not least I would like to thank all other sponsors for their support: EPITA, Université de Bordeaux, LispWorks, Franz Inc. I hope you enjoy your time at the 9th European Lisp Symposium and those few days you are spending in Poland. Michał Psota, Kraków, May 2016 Organization Programme Chair • Irène Anne Durand, University of Bordeaux, France Local Chair • Michał Psota — Emergent Network Defense, Kraków, Poland Programme Committee • Antonio Leitao — INESC-ID/IST, Universidade de Lisboa, Portugal • Charlotte Heerzel — IMEC, Leuven, Belgium • Christian Queinnec — University Pierre et Marie Curie, Paris 6, France • Christophe Rhodes — Goldsmiths, University of London, United Kingdom • Didier Verna — EPITA Research and Development Laboratory, France • Erick Gallesio — University of Nice-Sophia Antipolis, France • François-René Rideau, Google, USA • Giuseppe Attardi — University of Pisa, Italy • Kent Pitman, HyperMeta Inc., USA • Leonie Dreschler-Fischer — University of Hamburg, Germany • Pascal Costanza — Intel Corporation, Belgium • Robert Strandh — University of Bordeaux, France Organizing Committee • Michał Psota — Emergent Network Defense, Kraków, Poland • Maciej Ciołek — Scientific Society BIT, AGH University of Science and Technology, Kraków, Poland ELS 2016 xi Sponsors We gratefully acknowledge the support given to the 9thth European Lisp Symposium by the following sponsors: AGH University of Science and Technology Kraków, Poland www.agh.edu.pl/en Kolo Naukowe Kraków, Poland http://knbit. edu.pl/en/ EPITA 14-16 rue Voltaire FR-94276 Le Kremlin-Bicêtre CEDEX France www.epita.fr Université de Bordeaux Excellence Initiative Collège Science et Technologie 351 cours de la libération 33405 Talence Cedex France www.u-bordeaux.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 xii ELS 2016 Invited Contributions Program Proving with Coq Pierre Castéran, LaBRI, University of Bordeaux, France This talk aims to present some aspects of the Coq proof assistant, mainly the possibility of veri- fying and/or synthesizing correct programs. The talk will start with an introduction to the main features of Coq, both as a statically typed functional programming language and as a proof assistant, i.e. a tool for helping its user to prove theorems, including — but not limited to — correctness statements about his/her pro- grams. In the second part of the talk, we propose to use the efficient computation of powers of the form xn as a pretext for presenting various techniques for obtaining certified programs within the Coq system, with various levels of automaticity. Besides “classical” proof methods, we will present briefly some approaches and compare them with respect to their ability to efficiently return correctness proofs. • Proof by reflection, • The “refinement for free” approach, • Composition of certified components (correctness by construction) Pierre Castéran is an associate professor at the University of Bordeaux. His research interests are type theory, interactive theorem proving and programming language semantics. He co-authored the book on Coq: "Interactive Theorem Proving and Program Development" with Yves Bertot, and is the scientific co-organizer of 7 international summer schools on Coq, 2 in Paris, 4 in China, and 1 in Japan. He also co- authored two tutorials on advanced features of Coq: inductive and co- inductive types, type classes and generalized rewriting. Pierre Castéran is now working on a sequel of the aforementionned book, dedicated to the presentation of recent trends in using the Coq proof assistant. Pierre Castéran is one of the nine co-laureates of the ACM Software Systems Award given to the Coq Proof Assistant (2013). ∗ ∗ ∗ ∗ ∗ Julia: to Lisp or Not to Lisp? Stefan Karpinski, Julia Computing and New York University, New York, USA Julia is a general purpose dynamic language, designed to make numerical computing fast and convenient. Many aspects of Julia should be quite familiar since they are "stolen" straight from Lisp: it’s expression-oriented, lexically scoped, has closures, coroutines, and macros that oper- ate on code as data. But Julia departs from the Lisp tradition in other ways. Julia has syntax – lots of
Recommended publications
  • Formal Verification of Eccs for Memories Using ACL2

    Formal Verification of Eccs for Memories Using ACL2

    Journal of Electronic Testing (2020) 36:643–663 https://doi.org/10.1007/s10836-020-05904-2 Formal Verification of ECCs for Memories Using ACL2 Mahum Naseer1 · Waqar Ahmad1 · Osman Hasan1 Received: 12 April 2020 / Accepted: 2 September 2020 / Published online: 26 September 2020 © Springer Science+Business Media, LLC, part of Springer Nature 2020 Abstract Due to the ever-increasing toll of soft errors in memories, Error Correction Codes (ECCs) like Hamming and Reed-Solomon Codes have been used to protect data in memories, in applications ranging from space to terresterial work stations. In past seven decades, most of the research has focused on providing better ECC strategies for data integrity in memories, but the same pace research efforts have not been made to develop better verification methodologies for the newer ECCs. As the memory sizes keep increasing, exhaustive simulation-based testing of ECCs is no longer practical. Hence, formal verification, particularly theorem proving, provides an efficient, yet scarcely explored, alternative for ECC verification. We propose a framework, with extensible libraries, for the formal verification of ECCs using the ACL2 theorem prover. The framework is easy to use and particularly targets the needs of formally verified ECCs in memories. We also demonstrate the usefulness of the proposed framework by verifying two of the most commonly used ECCs, i.e., Hamming and Convolutional codes. To illustrate that the ECCs verified using our formal framework are practically reliable, we utilized a formal record- based memory model to formally verify that the inherent properties of the ECCs like hamming distance, codeword decoding, and error detection/correction remain consistent even when the ECC is implemented on the memory.
  • Little Languages for Little Robots

    Little Languages for Little Robots

    Little Languages for Little Robots Matthew C. Jadud Brooke N. Chenoweth Jacob Schleter University of Kent Canterbury Indiana University Gibson High School Canterbury, UK Bloomington Fort Branch, IN [email protected] Bloomington, IN [email protected] ABSTRACT where students learn by building personally meaningful With serendipity as our muse, we have created tools that artifacts in the world. allow students to author languages of their own design for robots of their own construction. In developing a Scheme 2. JACKLL: A NEW LANGUAGE compiler for the LEGO Mindstorm we realized that there In building up to the evolution of Jackll and the philoso- is great educational potential in the design and creation phies its creation embodies, we feel it is appropriate to of new languages for small robotics kits. As a side effect first introduce the LEGO Mindstorm, the target for our of bringing Scheme and the Mindstorm together in a cre- Scheme compiler, and situate Jackll with respect to other ative context, we have begun an exploration of teaching languages intended for beginner programmers. language design that is fundamentally different from the treatment of the subject in traditional literature. 2.1 What is the LEGO Mindstorm? The LEGO Mindstorm Robotics Invention System is a 1. INTRODUCTION commercial product from the LEGO Group that provides Jacob Schleter, a rising senior at Gibson High School, Fort an inexpensive, reconfigurable platform for exploring robotics. Branch, Indiana, took part in the Indiana University Col- It comes standard with two motors, two touch sensors, one lege of Arts and Sciences Summer Research Experience for light sensor, and hundreds of pieces for assembling all sorts six weeks during the summer of 2002.
  • Creating Formally Verified Components for Layered

    Creating Formally Verified Components for Layered

    Creating Formally Verified Components for Layered Assurance with an LLVM to ACL2 Translator∗ y z David S. Hardin Jedidiah R. McClurg Jennifer A. Davis Advanced Technology Center Department of Computer Advanced Technology Center Rockwell Collins Science Rockwell Collins Cedar Rapids, IA, USA University of Colorado Cedar Rapids, IA, USA [email protected] Boulder, CO, USA [email protected] [email protected] ABSTRACT Keywords In our current work, we need to create a library of formally Formal verification, Theorem proving, ACL2, LLVM verified software component models from code that has been compiled (or decompiled) using the Low-Level Virtual Ma- 1. INTRODUCTION chine (LLVM) intermediate form; these components, in turn, are to be assembled into subsystems whose top-level assur- ance relies on the assurance of the individual components. \Remember that all models are wrong; the Thus, we have undertaken a project to build a translator practical question is how wrong do they have to from LLVM to the applicative subset of Common Lisp ac- be to not be useful." [2] { George Box, British cepted by the ACL2 theorem prover. Our translator pro- Statistician duces executable ACL2 specifications featuring tail recur- sion, as well as in-place updates via ACL2's single-threaded Layered assurance for software often requires the creation object (stobj) mechanism. This allows us to efficiently sup- of a library of assured software component models, start- port validation of our models by executing production tests ing with code that lacks a formal pedigree. These assured for the original artifacts against those models. Unfortu- components can then be assembled into subsystems whose nately, features that make a formal model executable are of- top-level assurance relies on the assurance of the individual ten at odds with efficient reasoning.
  • Checking Nuprl Proofs in ACL2: a Progress Report

    Checking Nuprl Proofs in ACL2: a Progress Report

    Checking Nuprl Proofs in ACL2: A Progress Report James L. Caldwell? and John Cowles? Department of Computer Science, University of Wyoming, Laramie Wyoming {jlc,cowles}@cs.uwyo.edu Abstract. Stipulations on the correctness of proofs produced in a for- mal system include that the axioms and proof rules are the intended ones and that the proof has been properly constructed (i.e. it is a correct in- stantiation of the axioms and proof rules.) In software implementations of formal systems, correctness additionally depends both on the correct- ness of the program implementing the system and on the hardware it is executed on. Once we implement a system in software and execute it on a computer, we have moved from the abstract world of mathematics into the physical world; absolute correctness can never be achieved here. We can only strive to increase our confidence that the system is producing correct results. In the process of creating proofs, foundational systems like Nuprl construct formal proof objects. These proof objects can be independently checked to verify they are correct instantiations of the axioms and proof rules thereby increasing confidence that the putative proof object faithfully represents a proof in the formal system. Note that this kind of proof checking does not address issues related to the models of the proof system, it simply provides more evidence that a proof has been correctly constructed. The Nuprl implementation consists of more than 100K lines of LISP and tactic code implemented in ML. Although parts of the system consist of legacy codes going as far back as the late 1970’s (Edinburgh LCF), and even though the Nuprl system has been extensively used since 1986 in formalizing a significant body of mathe- matics, the chances that the implementation is correct are slim.
  • The Machine That Builds Itself: How the Strengths of Lisp Family

    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.
  • How to Design Co-Programs

    How to Design Co-Programs

    JFP, 15 pages, 2021. c Cambridge University Press 2021 1 doi:10.1017/xxxxx EDUCATIONMATTERS How to Design Co-Programs JEREMY GIBBONS Department of Computer Science, University of Oxford e-mail: [email protected] Abstract The observation that program structure follows data structure is a key lesson in introductory pro- gramming: good hints for possible program designs can be found by considering the structure of the data concerned. In particular, this lesson is a core message of the influential textbook “How to Design Programs” by Felleisen, Findler, Flatt, and Krishnamurthi. However, that book discusses using only the structure of input data for guiding program design, typically leading towards structurally recur- sive programs. We argue that novice programmers should also be taught to consider the structure of output data, leading them also towards structurally corecursive programs. 1 Introduction Where do programs come from? This mystery can be an obstacle to novice programmers, who can become overwhelmed by the design choices presented by a blank sheet of paper, or an empty editor window— where does one start? A good place to start, we tell them, is by analyzing the structure of the data that the program is to consume. For example, if the program h is to process a list of values, one may start by analyzing the structure of that list. Either the list is empty ([]), or it is non-empty (a : x) with a head (a) and a tail (x). This provides a candidate program structure: h [ ] = ::: h (a : x) = ::: a ::: x ::: where for the empty list some result must simply be chosen, and for a non-empty list the result depends on the head a and tail x.
  • Omnipresent and Low-Overhead Application Debugging

    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.
  • How Lisp Systems Look Different in Proceedings of European Conference on Software Maintenance and Reengineering (CSMR 2008)

    How Lisp Systems Look Different in Proceedings of European Conference on Software Maintenance and Reengineering (CSMR 2008)

    How Lisp Systems Look Different In Proceedings of European Conference on Software Maintenance and Reengineering (CSMR 2008) Adrian Dozsa Tudor Gˆırba Radu Marinescu Politehnica University of Timis¸oara University of Berne Politehnica University of Timis¸oara Romania Switzerland Romania [email protected] [email protected] [email protected] Abstract rently used in a variety of domains, like bio-informatics (BioBike), data mining (PEPITe), knowledge-based en- Many reverse engineering approaches have been devel- gineering (Cycorp or Genworks), video games (Naughty oped to analyze software systems written in different lan- Dog), flight scheduling (ITA Software), natural language guages like C/C++ or Java. These approaches typically processing (SRI International), CAD (ICAD or OneSpace), rely on a meta-model, that is either specific for the language financial applications (American Express), web program- at hand or language independent (e.g. UML). However, one ming (Yahoo! Store or reddit.com), telecom (AT&T, British language that was hardly addressed is Lisp. While at first Telecom Labs or France Telecom R&D), electronic design sight it can be accommodated by current language inde- automation (AMD or American Microsystems) or planning pendent meta-models, Lisp has some unique features (e.g. systems (NASA’s Mars Pathfinder spacecraft mission) [16]. macros, CLOS entities) that are crucial for reverse engi- neering Lisp systems. In this paper we propose a suite of Why Lisp is Different. In spite of its almost fifty-year new visualizations that reveal the special traits of the Lisp history, and of the fact that other programming languages language and thus help in understanding complex Lisp sys- borrowed concepts from it, Lisp still presents some unique tems.
  • Praise for Practical Common Lisp

    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.
  • Allegro CL User Guide

    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
  • Texing in Emacs Them

    Texing in Emacs Them

    30 TUGboat, Volume 39 (2018), No. 1 TEXing in Emacs them. I used a simple criterion: Emacs had a nice tutorial, and Vim apparently did not (at that time). Marcin Borkowski I wince at the very thought I might have chosen Abstract wrong! And so it went. I started with reading the In this paper I describe how I use GNU Emacs to manual [8]. As a student, I had a lot of free time work with LAT X. It is not a comprehensive survey E on my hands, so I basically read most of it. (I still of what can be done, but rather a subjective story recommend that to people who want to use Emacs about my personal usage. seriously.) I noticed that Emacs had a nice TEX In 2017, I gave a presentation [1] during the joint mode built-in, but also remembered from one of GUST/TUG conference at Bachotek. I talked about the BachoTEXs that other people had put together my experiences typesetting a journal (Wiadomo´sci something called AUCTEX, which was a TEX-mode Matematyczne, a journal of the Polish Mathematical on steroids. Society), and how I utilized LAT X and GNU Emacs E In the previous paragraph, I mentioned modes. in my workflow. After submitting my paper to the In order to understand what an Emacs mode is, let proceedings issue of TUGboat, Karl Berry asked me me explain what this whole Emacs thing is about. whether I'd like to prepare a paper about using Emacs with LATEX. 1 Basics of Emacs Well, I jumped at the proposal.
  • Proceedings of the 8Th European Lisp Symposium Goldsmiths, University of London, April 20-21, 2015 Julian Padget (Ed.) Sponsors

    Proceedings of the 8Th European Lisp Symposium Goldsmiths, University of London, April 20-21, 2015 Julian Padget (Ed.) Sponsors

    Proceedings of the 8th European Lisp Symposium Goldsmiths, University of London, April 20-21, 2015 Julian Padget (ed.) Sponsors We gratefully acknowledge the support given to the 8th European Lisp Symposium by the following sponsors: WWWLISPWORKSCOM i Organization Programme Committee Julian Padget – University of Bath, UK (chair) Giuseppe Attardi — University of Pisa, Italy Sacha Chua — Toronto, Canada Stephen Eglen — University of Cambridge, UK Marc Feeley — University of Montreal, Canada Matthew Flatt — University of Utah, USA Rainer Joswig — Hamburg, Germany Nick Levine — RavenPack, Spain Henry Lieberman — MIT, USA Christian Queinnec — University Pierre et Marie Curie, Paris 6, France Robert Strandh — University of Bordeaux, France Edmund Weitz — University of Applied Sciences, Hamburg, Germany Local Organization Christophe Rhodes – Goldsmiths, University of London, UK (chair) Richard Lewis – Goldsmiths, University of London, UK Shivi Hotwani – Goldsmiths, University of London, UK Didier Verna – EPITA Research and Development Laboratory, France ii Contents Acknowledgments i Messages from the chairs v Invited contributions Quicklisp: On Beyond Beta 2 Zach Beane µKanren: Running the Little Things Backwards 3 Bodil Stokke Escaping the Heap 4 Ahmon Dancy Unwanted Memory Retention 5 Martin Cracauer Peer-reviewed papers Efficient Applicative Programming Environments for Computer Vision Applications 7 Benjamin Seppke and Leonie Dreschler-Fischer Keyboard? How quaint. Visual Dataflow Implemented in Lisp 15 Donald Fisk P2R: Implementation of