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.