DOCSLIB.ORG

An Adaptive Package Management System for Scheme

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
An Adaptive Package Management System for Scheme An Adaptive Package Management System for Scheme Manuel Serrano Erick Gallesio Inria Sophia Antipolis Universit´e de Nice – Inria Sophia Antipolis 2004 route des Lucioles - BP 93 F-06902 Sophia 930 route des Colles, BP 145, F-06903 Sophia Antipolis, Cedex, France Antipolis, Cedex, France http://www.inria.fr/mimosa/Manuel.Serrano http://www.essi.fr/˜eg Abstract plex flow control structures, or its support for proper tail- This paper presents a package management system for recursion. the Scheme programming language. It is inspired by the Another characteristic of Scheme is its size: it is incredi- Comprehensive Perl Archive Network (CPAN) and various bly small and compact. The, still official, report [3] describ- GNU/Linux distributions. It downloads, installs, and pre- ing the language requires no more than 50 pages, and it pares source codes for execution. It manages the depen- includes a formal semantics! This is sometimes an advan- dencies between packages. The main characteristic of this tage, for instance, for teaching. This is also a drawback. The system is its neutrality with respect to the various Scheme price to pay for this compactness is a severe lack of libraries. implementations. It is neutral with respect to the language Scheme does not provide the minimal set of primitives re- extensions that each Scheme implementation proposes and quired for writing any modern applications, such as appli- with respect to the execution environment of these imple- cations involving network communication, graphical inter- mentations. This allows the programmer to blend, within the faces, or multiples threads. same program, independent components which have been Implementing a naive interpreter or compiler is an easy developed and tested within different Scheme implementa- task since Scheme is small. Hence, it is no surprise that tions. ScmPkg is available at: Scheme has so many different implementations. They all http://hop.inria.fr/hop/scmpkg have different flavors and tastes. Some promote a read-eval- print loop interaction. Some promote batch compilations. Categories and Subject Descriptors D.2.11 [Software En- Some emphasize easy access to C or Java. etc. Because gineering]: Software Architectures—Languages; D.2.12 the language is unrealistically minimalist, each of its main [Software Engineering]: Interoperability—Interface defi- implementations provides numerous extensions. As we can nition languages; D.3.2 [Programming Languages]: Lan- see, Scheme is not a language, but a family of languages. guage Classifications—Applicative (functional) languages There are as many dialects of Scheme as implementations of Scheme and it is uncertain to execute a Scheme program General Terms Design, Languages within a different environment from the one it has been Keywords Functional programming implemented with. Scheme is yet another tower of Babel! The Scheme language is minimalist but its main imple- 1. Introduction mentations generally are not. In effect, current Scheme im- plementations offer means to program the modern appli- Scheme is a functional programming language which was cations depicted above since most of them provide an ob- created in the 1970s. Amongst the specific features of ject system, libraries for network programming, multiple Scheme, we can cite its Lisp like syntax, its (hygienic) threads, etc. As a consequence, the Scheme community is macro system which provides a powerful self-extension in fact fragmented in several implementation communities. mechanism, its support for continuation management with Today it is hardly possible to develop, maintain, and re- it call/cc operator which allows the expression of com- lease Scheme codes that could directly be used by several implementations although porting such codes from one im- plementation to another is generally easy since, as we have Permission to make digital or hard copies of all or part of this work for personal or seen before, implementations tend to offer similar features classroom use is granted without fee provided that copies are not made or distributed with slightly different interfaces. To our knowledge three en- for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute deavors, including the present study, are currently ongoing to lists, requires prior specific permission and/or a fee. to tackle the development of Scheme codes that can be run DLS’07, October 22, 2007, Montr´eal, Qu´ebec, Canada. Copyright c 2007 ACM 978-1-59593-868-8/07/0010. $5.00 65 on various implementations. They either follow a centrifugal applications blending packages implemented in several of approach or centripetal approach. these dialects. Reusing code written for a given Scheme dialect may • The centrifugal approach consists in attracting users by sometimes lead to poor performances on another implemen- enriching the language with enough extensions in order tation. Sometimes, it may use dialect features that are un- to bootstrap a portable package system. That is, if it is available or behave incorrectly on this implementation. In possible to extend the language with the libraries required such cases, it is suitable to tune the code for this implemen- to implement modern applications then the community tation. ScmPkg permits one to develop, when needed, im- could start contributing with new APIs and libraries. plementation specific adaptations that will be applied when • The centripetal approach consists in accepting the dif- a package is installed on a given Scheme dialect. Hopefully, ferences and idiosyncrasies of each implementation by not all the packages need to be tuned but this mechanism, proposing a framework that lets pristine Scheme codes which will be lenghtly decribed in Section 3, ensures a cor- coming from various implementations be integrated in- rect behaviour and correct performances of ScmPkg pack- side a single application or library. ages for each Scheme implementation. The next sections present the technical aspects of ScmPkg. ScmPkg, our proposal, belongs to the centripetal family. It First, in Section 2, we present the system per se and a small is not a language but a mere package repository, a couple application blending two dialects. Then, in Section 3, we of web services, and a set of conventions and rules. It rests present the Host Adaptation, that is the machinery that is on a pragmatic approach that could be described as a gentle deployed to let code written for one implementation be used bazaar as described in a famous paper by E. Raymond [5]. within another one. Section 4 briefly states the material The general idea is not to try to elaborate a system that which must be developed to offer ScmPkg on a new im- solves all problems that could be raised in all situations. By plementation. Finally, Section 5 presents the current status opposition, it is a system that tries to solve the problems of ScmPkg. that are raised by common practices. The ideas governing the design of ScmPkg are: 2. ScmPkg • Let users (i.e., Scheme programmers) continue to main- ScmPkg is a loose architecture that consists of a web server, tain their private practices. In particular, let users keep a simple Interface Desciption Language (IDL) for describing writing their code using the language and its extensions packages, and ad-hoc package managers that are provided by they like or they are used to. the Scheme implementations (that we henceforth denote as Scheme hosts, hosts,ordialects) that support ScmPkg. • Let users keep developing using the environment they like and when the code is ready, let them transform it into • The web server implements a graphical user interface for a package by automatic tools. browsing the packages, their documentation, and their source code. It also supports two services that are used for • Make the distance from a package to plain Scheme code installing the packages. The first one provides the whole so short that it could be almost possible for programming list of packages and the second implements downloading environments to use packages as regular source files. of individual packages. ScmPkg does not even pretend to address all the program- • An IDL describes the material exposed by a package mers problems of portability of Scheme code. It only claims along with some additional meta information. This IDL to permit one to write almost portable packages that can be is described in Section 2.3. used by several implementations, not by enforcing rules or • Each Scheme host that supports ScmPkg must provide by imposing language constructions, but by gently begging a package manager. This is a simple program that is in for fair use. So, ScmPkg goal does not consist in permitting charge of preparing a package for its host. This, in gen- the execution of all Scheme codes that are floating around on eral, involves downloading, preparing and installing the particular implementations. Codes which use features bound code. Optionally it may also compile the code. The pack- to one particular implementation are really unportable and age manager is the equivalent to the apt-get command ScmPkg is helpless for these codes. of GNU/Linux Debian distributions. We have evidence that the ScmPkg packaging system can be successful for reusing Scheme codes. Quite easily, In contrast to other approaches, ScmPkg does not rest on we have been able to feed our packaging system with more a unified framework for installing packages. This design than a hundred packages within a couple of weeks, by sim- choice is based on the observation that the process of in- ply grabbing code here and there. The system is operational stalling source code is highly dependent on the nature of for three Scheme implementations: Bigloo, STklos, and, par- the host. For instance, installing a package for a batch com- tially, MzScheme. It accepts source code coming from seven piler could mean to download it and its dependencies and Scheme dialects.
Load more

Recommended publications
  • Towards a Portable and Mobile Scheme Interpreter
    Towards a Portable and Mobile Scheme Interpreter Adrien Pi´erard Marc Feeley Universit´eParis 6 Universit´ede Montr´eal [email protected] [email protected] Abstract guage. Because Mobit implements R4RS Scheme [6], we must also The transfer of program data between the nodes of a distributed address the serialization of continuations. Our main contribution is system is a fundamental operation. It usually requires some form the demonstration of how this can be done while preserving the in- of data serialization. For a functional language such as Scheme it is terpreter’s maintainability and with local changes to the original in- clearly desirable to also allow the unrestricted transfer of functions terpreter’s structure, mainly through the use of unhygienic macros. between nodes. With the goal of developing a portable implemen- We start by giving an overview of the pertinent features of the tation of the Termite system we have designed the Mobit Scheme Termite dialect of Scheme. In Section 3 we explain the structure interpreter which supports unrestricted serialization of Scheme ob- of the interpreter on which Mobit is based. Object serialization is jects, including procedures and continuations. Mobit is derived discussed in Section 4. Section 5 compares Mobit’s performance from an existing Scheme in Scheme fast interpreter. We demon- with other interpreters. We conclude with related and future work. strate how macros were valuable in transforming the interpreter while preserving its structure and maintainability. Our performance 2. Termite evaluation shows that the run time speed of Mobit is comparable to Termite is a Scheme adaptation of the Erlang concurrency model.
    [Show full text]
  • Towards a Portable and Mobile Scheme Interpreter
    Towards a Portable and Mobile Scheme Interpreter Adrien Pi´erard Marc Feeley Universit´eParis 6 Universit´ede Montr´eal [email protected] [email protected] Abstract guage. Because Mobit implements R4RS Scheme [6], we must also The transfer of program data between the nodes of a distributed address the serialization of continuations. Our main contribution is system is a fundamental operation. It usually requires some form the demonstration of how this can be done while preserving thein- of data serialization. For a functional language such as Scheme it is terpreter’s maintainability and with local changes to the original in- clearly desirable to also allow the unrestricted transfer offunctions terpreter’s structure, mainly through the use of unhygienicmacros. between nodes. With the goal of developing a portable implemen- We start by giving an overview of the pertinent features of the tation of the Termite system we have designed the Mobit Scheme Termite dialect of Scheme. In Section 3 we explain the structure interpreter which supports unrestricted serialization of Scheme ob- of the interpreter on which Mobit is based. Object serialization is jects, including procedures and continuations. Mobit is derived discussed in Section 4. Section 5 compares Mobit’s performance from an existing Scheme in Scheme fast interpreter. We demon- with other interpreters. We conclude with related and futurework. strate how macros were valuable in transforming the interpreter while preserving its structure and maintainability. Our performance 2. Termite evaluation shows that the run time speed of Mobit is comparable to Termite is a Scheme adaptation of the Erlang concurrency model.
    [Show full text]
  • This Is the Author's Version of a Work Accepted for Publication by Elsevier
    NOTICE: This is the author’s version of a work accepted for publication by Elsevier. Changes resulting from the publishing process, including peer review, editing, corrections, structural formatting and other quality control mechanisms, may not be reflected in this document. A definitive version was subsequently published in the Journal of Systems and Software, Volume 86, Issue 2, pp. 278-301, February 2013. Efficient Support of Dynamic Inheritance for Class- and Prototype-based Languages Jose Manuel Redondo, Francisco Ortin University of Oviedo, Computer Science Department, Calvo Sotelo s/n, 33007, Oviedo, Spain Abstract Dynamically typed languages are becoming increasingly popular for different software devel- opment scenarios where runtime adaptability is important. Therefore, existing class-based plat- forms such as Java and .NET have been gradually incorporating dynamic features to support the execution of these languages. The implementations of dynamic languages on these platforms com- monly generate an extra layer of software over the virtual machine, which reproduces the reflective prototype-based object model provided by most dynamic languages. Simulating this model fre- quently involves a runtime performance penalty, and makes the interoperation between class- and prototype-based languages difficult. Instead of simulating the reflective model of dynamic languages, our approach has been to extend the object-model of an efficient class-based virtual machine with prototype-based seman- tics, so that it can directly support both kinds of languages. Consequently, we obtain the runtime performance improvement of using the virtual machine JIT compiler, while a direct interoperation between languages compiled to our platform is also possible. In this paper, we formalize dynamic inheritance for both class- and prototype-based languages, and implement it as an extension of an efficient virtual machine that performs JIT compilation.
    [Show full text]
  • Keyword and Optional Arguments in PLT Scheme
    Keyword and Optional Arguments in PLT Scheme Matthew Flatt Eli Barzilay University of Utah and PLT Northeastern University and PLT mfl[email protected] [email protected] Abstract (define rectangle The lambda and procedure-application forms in PLT Scheme sup- (lambda (width height #:color color) port arguments that are tagged with keywords, instead of identified ....)) by position, as well as optional arguments with default values. Un- or like previous keyword-argument systems for Scheme, a keyword is not self-quoting as an expression, and keyword arguments use (define (rectangle width height #:color color) ....) a different calling convention than non-keyword arguments. Con- sequently, a keyword serves more reliably (e.g., in terms of error This rectangle procedure could be called as reporting) as a lightweight syntactic delimiter on procedure argu- (rectangle 10 20 #:color "blue") ments. Our design requires no changes to the PLT Scheme core compiler, because lambda and application forms that support key- A keyword argument can be in any position relative to other argu- words are implemented by macros over conventional core forms ments, so the following two calls are equivalent to the preceding that lack keyword support. one: (rectangle #:color "blue" 10 20) 1. Using Keyword and Optional Arguments (rectangle 10 #:color "blue" 20) The #:color formal argument could have been in any position A rich programming language offers many ways to abstract and among the arguments in the definition of rectangle, as well. In parameterize code. In Scheme, first-class procedures are the pri- general, keyword arguments are designed to look the same in both mary means of abstraction, and procedures are unquestionably the the declaration and application of a procedure.
    [Show full text]
  • 4 European Lisp Symposium
    Proceedings of ELS 2011 4th European Lisp Symposium Special Focus on Parallelism and Efficiency March 31 – April 1 2011 TUHH, Hamburg, Germany Preface Message from the Programme Chair Welcome to ELS 2011, the 4th European Lisp Symposium. In the recent years, all major academic events have suffered from a decreasing level of atten- dance and contribution, Lisp being no exception to the rule. Organizing ELS 2011 in this context was hence a challenge of its own, and I’m particularly happy that we have succeeded again. For the first time this year, we had a “special focus” on parallelism and efficiency, all very im- portant matters for our community with the advent of multi-core programming. It appears that this calling has been largely heard, as half of the submissions were along these lines. Another notable aspect of this year’s occurrence is the fact that four dialects of Lisp are represented: Common Lisp, Scheme, Racket and Clojure. This indicates that ELS is successful in attempting to gather all crowds around Lisp “the idea” rather than around Lisp “one particular language”. The European Lisp Symposium is also more European than ever, and in fact, more international than ever, with people coming not only from western Europe and the U.S.A., but also from such countries as Croatia and Bulgaria. While attending the symposium is just seeing the tip of the iceberg, a lot have happened under- water. First of all, ELS 2011 would not have been possible without the submissions we got from the authors and the careful reviews provided by the programme committee members; I wish to thank them for that.
    [Show full text]
  • Benchmarking Implementations of Functional Languages With
    Benchmarking Implementations of Functional Languages with Pseudoknot a FloatIntensive Benchmark Pieter H Hartel Marc Feeley Martin Alt Lennart Augustsson Peter Baumann Marcel Beemster Emmanuel Chailloux Christine H Flo o d Wolfgang Grieskamp John H G van Groningen Kevin Hammond Bogumil Hausman Melo dy Y Ivory Richard E Jones Jasp er Kamp erman Peter Lee Xavier Leroy Rafael D Lins Sandra Lo osemore Niklas Rojemo Manuel Serrano JeanPierre Talpin Jon Thackray Stephen Thomas Pum Walters Pierre Weis Peter Wentworth Abstract Over implementation s of dierent functional languages are b enchmarked using the same program a oating p ointintensive application taken from molecular biology The principal asp ects studied are compile time and Dept of Computer Systems Univ of Amsterdam Kruislaan SJ Amsterdam The Netherlands email pieterfwiuvanl Depart dinformatique et ro Univ de Montreal succursale centreville Montreal HC J Canada email feeleyiroumontrealca Informatik Universitat des Saarlandes Saarbruc ken Germany email altcsunisbde Dept of Computer Systems Chalmers Univ of Technology Goteb org Sweden email augustsscschalmersse Dept of Computer Science Univ of Zurich Winterthurerstr Zurich Switzerland email baumanniunizh ch Dept of Computer Systems Univ of Amsterdam Kruislaan SJ Amsterdam The Netherlands email b eemsterfwiuvanl LIENS URA du CNRS Ecole Normale Superieure rue dUlm PARIS Cedex France email EmmanuelChaillou xensfr Lab oratory for Computer Science MIT Technology Square Cambridge Massachusetts
    [Show full text]
  • Bugloo: a Source Level Debugger for Scheme Programs Compiled Into JVM Bytecode
    Bugloo: A Source Level Debugger for Scheme Programs Compiled into JVM Bytecode Damien Ciabrini Manuel Serrano INRIA Sophia Antipolis INRIA Sophia Antipolis 2004 route des Lucioles - BP 93 2004 route des Lucioles - BP 93 F-06902 Sophia Antipolis, Cedex F-06902 Sophia Antipolis, Cedex [email protected] [email protected] ABSTRACT strated by a static debugger. Our work focuses on the dy- namic debugging approach and on the Scheme [20] program- This paper presents Bugloo, a source level debugger for ming language. Scheme programs. It enables debugging of programs com- piled into JVM bytecode by the Bigloo compiler. It aims 1.1 Motivation of Our Work at being easy to use because it provides a user interface. It In practice, programmers hardly use debuggers. Obviously, aims at being practical to use because it is easy to deploy they prefer ad hoc debugging techniques such as inserting and because it is efficient enough to debug large programs prints in the source code. We think that the reason of such as the Bigloo compiler itself. this disinterest is twofold: (i) many debuggers are not ef- ficient enough to debug large programs, (ii), features of- The JVM platform provides two standard APIs for imple- fered by many debuggers are unsufficient for the type of bug menting debuggers and profilers: JVMDI and JVMPI. One programmers have to correct. In consequence, they often of the motivations for providing the Bigloo compiler with a conclude that “prints are simpler and quicker”. In other JVM back-end was to benefit from these two APIs to imple- words, the overall benefits of debuggers might not be worth ment a debugger for Scheme.
    [Show full text]
  • Proceedings of the FREENIX Track: 2002 USENIX Annual Technical Conference
    USENIX Association Proceedings of the FREENIX Track: 2002 USENIX Annual Technical Conference Monterey, California, USA June 10-15, 2002 THE ADVANCED COMPUTING SYSTEMS ASSOCIATION © 2002 by The USENIX Association All Rights Reserved For more information about the USENIX Association: Phone: 1 510 528 8649 FAX: 1 510 548 5738 Email: [email protected] WWW: http://www.usenix.org Rights to individual papers remain with the author or the author's employer. Permission is granted for noncommercial reproduction of the work for educational or research purposes. This copyright notice must be included in the reproduced paper. USENIX acknowledges all trademarks herein. Biglook: a Widget Library for the Scheme Programming Language Erick Gallesio Manuel Serrano Universite´ de Nice – Sophia Antipolis Inria Sophia Antipolis 950 route des Colles, B.P. 145 2004 route des Lucioles – B.P. 93 F-06903 Sophia Antipolis, Cedex F-06902 Sophia-Antipolis, Cedex EÖickºGaÐÐe×iÓ@ÙÒiceºfÖ ÅaÒÙeкËeÖÖaÒÓ@iÒÖiaºfÖ Abstract Biglook is an Object Oriented Scheme library for constructing GUIs. It uses classes of a CLOS- like object layer to represent widgets and Scheme closures to handle events. Combining functional and object-oriented programming styles yields an original application programming interface that advocates a strict separation between the implementation of the graphical interfaces and the user-associated commands, enabling compact source code. The Biglook implementation separates the Scheme programming interface and the na- Figure 1: Two Biglook applications: a code tive back-end. This permits different ports browser on the left, “dock” applications on the for Biglook. The current version uses GTK· right and Swing graphical toolkits, while the pre- vious release used Tk.
    [Show full text]
  • Programming Language Support for Digitized Images Or, the Monsters in the Closet
    The following paper was originally published in the Proceedings of the Conference on Domain-Specific Languages Santa Barbara, California, October 1997 Programming Language Support for Digitized Images or, The Monsters in the Closet Daniel E. Stevenson and Margaret M. Fleck University of Iowa For more information about USENIX Association contact: 1. Phone: 510 528-8649 2. FAX: 510 548-5738 3. Email: [email protected] 4. WWW URL:http://www.usenix.org Programming Language Supp ort for Digitized Images or, The Monsters in the Closet y Daniel E. Stevenson Margaret M. Fleck Department of Computer Science Departmentof Computer Science University of Iowa University of Iowa Iowa City,IA 52242, USA Iowa City, IA 52242, USA Abstract rapid spread of images is particularly obvious on the World-Wide Web. Although many users require only image pro cessing Computer vision image understanding algorithms and graphics packages e.g. xv, Photoshop, an in- are dicult to write, debug, maintain, and share. creasing range of applications require basic image This complicates col laboration, teaching, and repli- understanding. For example, researchers in the sci- cation of research results. This paper shows how ences and medicine use images to measure physical user-level code can be simpli ed by providing bet- prop erties e.g. blood vessel width and screen for ter programming language constructs, particularly interesting events e.g. unusual cell shap es. Com- a new abstract data type cal led a \sheet." These panies, governments, non-pro t organizations e.g. primitives have been implemented as an extension museums, and private citizens are converting photo to Scheme.
    [Show full text]
  • 2010 Workshop on Scheme and Functional Programming
    2010 Workshop on Scheme and Functional Programming Montreal,´ Quebec,´ Canada Saturday and Sunday August 21-22, 2010 2 Preface This report contains the papers presented at the Eleventh Workshop on Scheme and Functional Programming, held on Saturday and Sunday, August 21 and 22, 2010 at the Universite´ de Montreal.´ Eight papers were submitted in response to the call for papers. Each paper was evaluated by three reviewers. After due deliberation, the program committee decided to accept all papers. This year the program includes lightning talks which we hope will help the exchange of new ideas and developments between the participants. We thank Olin Shivers and Robby Findler who have graciously accepted our invitation to present their work. The Scheme Language committees will report on their progress towards the next Scheme standard. The workshop has been extended from its traditional one day format to a day and a half to accommodate all of the presentations. Finally we would like to thank Robby Findler for helping out with the formatting of the proceedings, and Virginie Allard-Cameus,´ Marie-Josee´ Boulay, and Line Pariseau for taking care of the catering and other local arrangements. Marc Feeley Universite´ de Montreal´ Organizer and Program Chair Program Committee Alan Bawden (independent consultant) Felix S. Klock II (Adobe Systems Incorporated) Olivier Danvy (Aarhus University) Jay McCarthy (Brigham Young University) Christopher Dutchyn (University of Saskatchewan) Scott McKay (ITA software) Marc Feeley (Universite´ de Montreal)´ Steering Committee William D. Clinger (Northeastern University) Christian Queinnec (Universite´ Pierre et Marie Curie) Marc Feeley (Universite´ de Montreal)´ Manuel Serrano (INRIA Sophia Antipolis) Robby Findler (Northwestern University) Olin Shivers (Northeastern University) Dan Friedman (Indiana University) Mitchell Wand (Northeastern University) 3 4 Schedule & Table of Contents Saturday, August 21 8:15 On-site registration and breakfast 9:00 Invited Talk: Eager parsing and user interaction with call/cc ........................
    [Show full text]
  • 23 Things I Know About Modules for Scheme
    23 things I know about modules for Scheme Christian Queinnec Université Paris 6 — Pierre et Marie Curie LIP6, 4 place Jussieu, 75252 Paris Cedex — France [email protected] ABSTRACT ables), types, classes (and their cortege` of accessors, con- The benefits of modularization are well known. However, modules structors and predicates) ? are not standard in Scheme. This paper accompanies an invited talk The usual answer in Scheme is to share locations with (quite at the Scheme Workshop 2002 on the current state of modules for often) two additional properties: (i) these locations can only Scheme. Implementation is not addressed, only linguistic features be mutated from the body of their defining modules (this fa- are covered. vors block compilation), (ii) they should hold functions (and Cave lector, this paper only reflects my own and instantaneous this should be statically (and easily) discoverable). This biases! restricts linking with other (foreign) languages that may ex- port locations holding non-functional data (the errno loca- 1. MODULES tion for instance). This is not a big restriction since modern interfaces (Corba for example) tend to exclusively use func- The benefits of modularization within conventional languages tions (or methods). On the good side, this restriction allows are well known. Modules dissociate interfaces and implementa- for better compilation since non mutated exported functions tions; they allow separate compilation (or at least independent com- may be directly invoked or inlined. pilation a` la C). Modules tend to favor re-usability, common li- braries and cross language linkage. Let us remark that values, if staying in an entirely Scheme Modules discipline name spaces with explicit names exposure, world, would be sufficient since closures are values giving hiding or renaming.
    [Show full text]
  • Proceedings of ELS 2013 6Th European Lisp Symposium June 3 – 4 2013 Madrid, Spain
    Proceedings of ELS 2013 6th European Lisp Symposium June 3 – 4 2013 Madrid, Spain Organization Programme Chairs • Christian Queinnec, UPMC, France • Manuel Serrano, INRIA, France Local Chair • Juan José Garcia-Ripoll, IFF, Madrid Programme Committee • Pascal Costanza, Intel, Belgium • Ludovic Courtès, Inria, France • Theo D’Hondt, Vrije Universiteit Brussel, Belgium • Erick Gallesio, University of Nice-Sophia Antipolis • Florian Loitsch, Google, Denmark • Kurt Noermark, Aalborg University, Denmark • Christian Queinnec, UPMC, France • Olin Shivers, Northeastern University, USA • Manuel Serrano, Inria, France • Didier Verna, Epita Research Lab, France ELS 2013 iii Sponsors EPITA 14-16 rue Voltaire FR-94276 Le Kremlin-Bicêtre CEDEX France www.epita.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 Clozure Associates Boston, MA 02205-5071 USA www.clozure.com INRIA Domaine de Voluceau Rocquencourt - BP 105 78153 Le Chesnay Cedex France www.inria.fr Association of Lisp Users USA www.alu.org iv ELS 2013 Contents Organization iii Programme Chairs . iii Local Chair . iii Programme Committee . iii Sponsors . iv Invited Talks 1 Asynchronous Programming in Dart – Florian Loitsch ...................1 Lisp and Music Research – Gérard Assayag ..........................1 Streams-Based, Multi-Threaded News Classification – Jason Cornez ...........1 Session I 3 Functional Package Management with Guix – Ludovic Courtès ..............4 Data-Transformer: an Example of Data-Centered Toolset – Mikhail Raskin ........ 15 The Leonardo System and Software Individuals – Erik Sandewall ............. 18 Session II 25 Tutorial: Typed Racket – Sam Tobin-Hochstadt ........................ 26 Platforms for Games and Evaluation of Lisp Code – Arturo de Salabert .........
    [Show full text]