DOCSLIB.ORG

2006 Scheme and Functional Programming Papers, University of Chicago TR-2006-06

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

λλλλλλλλλλλ λλ λ λλ λ λ λ λ λ λ λ λ λ λ λ λ λ λ λλ λ λ λ λ λλ λλ λ λ λλ λ λ λλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλ Scheme and λλFunctionalλλλλλλλλλλλλλλλλλλλλλλλλλ Programming λλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλ2006λλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλ Preface This report contains the papers presented at the Seventh Workshop on Scheme and Functional Program- ming, held on Sunday, September 17, 2006 in Portland, Oregon, affiliated with the 2006 International Conference on Functional Programming (ICFP). Out of sixteen papers submitted in response to the call for papers, fifteen were chosen for publication by the program committee in a virtual meeting (one was later withdrawn by its author). We are grateful to external reviewers Matthias Blume (Toyota Technological Institute Chicago), Matthew Flatt (University of Utah), Martin Gasbichler (University of Tubingen),¨ Aaron Keen (Cal Poly), George Kuan (University of Chicago), Jacob Matthews (University of Chicago), Christian Queinnec (University Paris 6), and Adam Wick (University of Utah) for their gracious help. Paper submission and review were managed by the Continue server (http://continue.cs.brown. edu), implemented in Scheme, of course. Thanks to Jay McCarthy and Shriram Krishnamurthi who provided and supported the server. Olin Shivers’ writeup of the 2002 Scheme workshop proved invaluable in organizing this one, as did timely advice from Matthias Felleisen, Mike Sperber, and the steering committee. Thanks also to the ICFP general chair John Reppy, the local arrangements chair Jim Hook, and the ACM for handling registrations and arrangements at the workshop site. Robby Findler University of Chicago Organizer and Program Chair for the program committee Program Committee John Clements (Cal Poly) Cormac Flanagan (UC Santa Cruz) Sebastian Egner (Philips Research) Erik Hilsdale (Google) Robby Findler (University of Chicago) Eric Knauel (University of Tubingen)¨ Steering Committee William D. Clinger (Northeastern University) Christian Queinnec (University Paris 6) Marc Feeley (Universite´ de Montreal)´ Manuel Serrano (INRIA Sophia Antipolis) Robby Findler (University of Chicago) Olin Shivers (Georgia Tech) Dan Friedman (Indiana University) Mitchell Wand (Northeastern University) Scheme and Functional Programming, 2006 3 4 Scheme and Functional Programming, 2006 Schedule & Table of Contents 8:30am Invited Talk: The HOP Development Kit .................................................. 7 Manuel Serrano (Inria Sophia Antipolis) A Stepper for Scheme Macros ............................................................ 15 Ryan Culpepper, Matthias Felleisen (Northeastern University) 10:00am Break 10:30am An Incremental Approach to Compiler Construction ..................................... 27 Abdulaziz Ghuloum (Indiana University) SHard: a Scheme to Hardware Compiler ................................................. 39 Xavier Saint-Mleux (Universit´ede Montr´eal),Marc Feeley (Universit´ede Montr´eal)and Jean-Pierre David (Ecole´ Polytechnique de Montr´eal) Automatic construction of parse trees for lexemes ........................................ 51 Danny Dub´e(Universit´eLaval) and Anass Kadiri (EPITA, Paris France) Rapid Case Dispatch in Scheme .......................................................... 63 William D. Clinger (Northeastern University) Experiences with Scheme in an Electro-Optics Laboratory ............................... 71 Richard Cleis and Keith Wilson (Air Force Research Laboratory) 12:30pm Lunch 2:00pm Gradual Typing for Functional Languages ............................................... 81 Jeremy G. Siek and Walid Taha (Rice University) Sage: Hybrid Checking for Flexible Specifications ....................................... 93 Jessica Gronski (University of California, Santa Cruz (UCSC)), Kenneth Knowles (UCSC), Aaron Tomb (UCSC), Stephen N. Freund (Williams College), and Cormac Flanagan (UCSC) From Variadic Functions to Variadic Relations: A miniKanren Perspective . 105 William E. Byrd and Daniel P. Friedman (Indiana University) 3:30pm Break 4:00pm A Self-Hosting Evaluator using HOAS .................................................. 119 Eli Barzilay (Northeastern University) Concurrency Oriented Programming in Termite Scheme ................................ 125 Guillaume Germain, Marc Feeley, Stefan Monnier (Universit´ede Montr´eal) Interaction-Safe State for the Web ....................................................... 137 Jay McCarthy and Shriram Krishnamurthi (Brown University) Scheme for Client-Side Scripting in Mobile Web Browsing, or AJAX-Like Behavior Without Javascript .............................................. 147 Ray Rischpater (Rocket Mobile, Inc.) Component Deployment with PLaneT: You Want it Where? ............................. 157 Jacob Matthews (University of Chicago) 6:10pm Break for dinnner 8:00pm Gelato 8:15pm R6RS Status Report Kent Dybvig (Indiana University) Scheme and Functional Programming, 2006 5 6 Scheme and Functional Programming, 2006 The HOP Development Kit Manuel Serrano Inria Sophia Antipolis 2004 route des Lucioles - BP 93 F-06902 Sophia Antipolis, Cedex, France http://www.inria.fr/mimosa/Manuel.Serrano ABSTRACT for building HTML graphical user interfaces is presented here. It Hop, is a language dedicated to programming reactive and dynamic is presented in Section 2, along with a presentation of the Hop applications on the web. It is meant for programming applications solution for bringing abstraction to Cascade Style Sheets. such as web agendas, web galleries, web mail clients, etc. While The section 3 focuses on programming the Hop web broker. a previous paper (Hop, a Language for Programming the Web Its presents basic handling of client requests and it presents the 2.0, available at http://hop.inria.fr) focused on the linguistic facilities for connecting two brokers and for gathering information novelties brought by Hop, the present one focuses on its execution scattered on the internet. The Section 4 presents the main functions environment. That is, it presents Hop’s user libraries, its extensions of the broker programming library. to the HTML-based standards, and its execution platform, the Hop web broker. 1.1 The web 2.0 In the newsgroup comp.lang.functional, a Usenet news group DOWNLOAD for computer scientists (if not researchers in computer science) someone reacted rather badly to the official announce of the avail- Hop is available at: http://hop.inria.fr. ability of the first version Hop: “I really don’t understand why people are [so] hyped-up over The web site contains the distribution of the source code, the Web 2.0. It’s just Java reborn with a slower engine that doesn’t online documentation, and various demonstrations. even have sandboxing capabilities built into it. I guess this hype will taper off just like the Java hype, leaving us with yet another 1. Introduction large technology and a few niches where it’s useful.” Along with games, multimedia applications, and email, the web This message implicitly compares two programming languages, has popularized computers in everybody’s life. The revolution is namely Java and JavaScript and reduces Hop to yet another engaged and we may be at the dawn of a new era of computing general-purpose programming language. This is a misunderstand- where the web is a central element. ing. The point of Hop is to help writing new applications that are Many of the computer programs we write, for professional nearly impossible (or at least, discouragingly tedious) to write us- purposes or for our own needs, are likely to extensively use the ing traditional programming languages such as Java and the like. As web. The web is a database. The web is an API. The web is a novel such, its goal is definitively not to compete with these languages. architecture. Therefore, it needs novel programming languages and As a challenge, imagine implementing a program that represents novel programming environments. Hop is a step in this direction. the user with a map of the United States of America that : lets the A previous paper [1] presented the Hop programming language. user zoom in and out on the map, and also helps with trip planning. This present paper presents the Hop execution environment. The In particular the user may click on two cities, and the application rest of this section presents the kind of end-user applications Hop responds with the shortest route between the cities, the estimated focuses on (Section 1.1) and the technical solutions it promotes trip time, the price of the gas for the trip (using local pump prices) (Section 1.2). The rest of this paper assumes a familiarity with strict the weather forecasts along the route (for the appropriate tires), and functional languages and with infix parenthetical syntaxes such as where to find the best pizza and gelatos in each town along the way. the ones found in Lisp and Scheme. Although it is possible to write such a program using Java or C and Because it is normal for a web application to access databases, existing resources available online, the web 2.0 is the infrastructure manipulate multimedia documents (images, movies, and music), that makes it feasible to write such programs. Because the web and parse files according to public formats, programming the web 2.0 provides the potential to easily combine fancy graphics and demands a lot of libraries. Even though it is still young, Hop information from disparate
Recommended publications
  • Compiler Error Messages Considered Unhelpful: the Landscape of Text-Based Programming Error Message Research

    Compiler Error Messages Considered Unhelpful: the Landscape of Text-Based Programming Error Message Research

    Working Group Report ITiCSE-WGR ’19, July 15–17, 2019, Aberdeen, Scotland Uk Compiler Error Messages Considered Unhelpful: The Landscape of Text-Based Programming Error Message Research Brett A. Becker∗ Paul Denny∗ Raymond Pettit∗ University College Dublin University of Auckland University of Virginia Dublin, Ireland Auckland, New Zealand Charlottesville, Virginia, USA [email protected] [email protected] [email protected] Durell Bouchard Dennis J. Bouvier Brian Harrington Roanoke College Southern Illinois University Edwardsville University of Toronto Scarborough Roanoke, Virgina, USA Edwardsville, Illinois, USA Scarborough, Ontario, Canada [email protected] [email protected] [email protected] Amir Kamil Amey Karkare Chris McDonald University of Michigan Indian Institute of Technology Kanpur University of Western Australia Ann Arbor, Michigan, USA Kanpur, India Perth, Australia [email protected] [email protected] [email protected] Peter-Michael Osera Janice L. Pearce James Prather Grinnell College Berea College Abilene Christian University Grinnell, Iowa, USA Berea, Kentucky, USA Abilene, Texas, USA [email protected] [email protected] [email protected] ABSTRACT of evidence supporting each one (historical, anecdotal, and empiri- Diagnostic messages generated by compilers and interpreters such cal). This work can serve as a starting point for those who wish to as syntax error messages have been researched for over half of a conduct research on compiler error messages, runtime errors, and century. Unfortunately, these messages which include error, warn- warnings. We also make the bibtex file of our 300+ reference corpus ing, and run-time messages, present substantial difficulty and could publicly available.
  • Introduction Code Reuse

    Introduction Code Reuse

    The Sather Language: Efficient, Interactive, Object-Oriented Programming Stephen Omohundro Dr. Dobbs Journal Introduction Sather is an object oriented language which aims to be simple, efficient, interactive, safe, and non-proprietary. One way of placing it in the "space of languages" is to say that it aims to be as efficient as C, C++, or Fortran, as elegant and safe as Eiffel or CLU, and to support interactive programming and higher-order functions as well as Common Lisp, Scheme, or Smalltalk. Sather has parameterized classes, object-oriented dispatch, statically-checked strong typing, separate implementation and type inheritance, multiple inheritance, garbage collection, iteration abstraction, higher-order routines and iters, exception handling, constructors for arbitrary data structures, and assertions, preconditions, postconditions, and class invariants. This article describes the first few of these features. The development environment integrates an interpreter, a debugger, and a compiler. Sather programs can be compiled into portable C code and can efficiently link with C object files. Sather has a very unrestrictive license which allows its use in proprietary projects but encourages contribution to the public library. The original 0.2 version of the Sather compiler and tools was made available in June 1991. This article describes version 1.0. By the time the article appears, the combined 1.0 compiler/interpreter/debugger should be available on "ftp.icsi.berkeley.edu" and the newsgroup "comp.lang.sather" should be activated for discussion. Code Reuse The primary benefit promised by object-oriented languages is reuse of code. Sather programs consist of collections of modules called "classes" which encapsulate well-defined abstractions.
  • 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.
  • Panel: NSF-Sponsored Innovative Approaches to Undergraduate Computer Science

    Panel: NSF-Sponsored Innovative Approaches to Undergraduate Computer Science

    Panel: NSF-Sponsored Innovative Approaches to Undergraduate Computer Science Stephen Bloch (Adelphi University) Amruth Kumar (Ramapo College) Stanislav Kurkovsky (Central CT State University) Clif Kussmaul (Muhlenberg College) Matt Dickerson (Middlebury College), moderator Project Web site(s) Intervention Delivery Supervision Program http://programbydesign.org curriculum with supporting in class; software normally active, but can be by Design http://picturingprograms.org IDE, libraries, & texts and textbook are done other ways Stephen Bloch http://www.ccs.neu.edu/home/ free downloads matthias/HtDP2e/ or web-based NSF awards 0010064 http://racket-lang.org & 0618543 http://wescheme.org Problets http://www.problets.org in- or after-class problem- applet in none - teacher not needed, Amruth Kumar solving exercises on a browser although some adopters use programming concepts it in active mode too NSF award 0817187 Mobile Game http://www.mgdcs.com/ in-class or take-home PC passive - teacher as Development programming projects facilitator to answer Qs Stan Kurkovsky NSF award DUE-0941348 POGIL http://pogil.org in-class activity paper or web passive - teacher as Clif Kussmaul http://cspogil.org facilitator to answer Qs NSF award TUES 1044679 Project Course(s) Language(s) Focus Program Middle school, Usually Scheme-like teaching problem-solving process, by pre-AP CS in HS, languages leading into Java; particularly test-driven DesignStephen CS0, CS1, CS2 has also been done in Python, development and use of data Bloch in college ML, Java, Scala, ... types to guide coding & testing Problets AP-CS, CS I, CS 2. C, C++, Java, C# code tracing, debugging, Amruth Kumar also as refresher or expression evaluation, to switch languages predicting program state in other courses Mobile Game AP-CS, CS1, CS2 Java core OO programming; DevelopmentSt intro to advanced subjects an Kurkovsky such as AI, networks, security POGILClif CS1, CS2, SE, etc.
  • An Optimized R5RS Macro Expander

    An Optimized R5RS Macro Expander

    An Optimized R5RS Macro Expander Sean Reque A thesis submitted to the faculty of Brigham Young University in partial fulfillment of the requirements for the degree of Master of Science Jay McCarthy, Chair Eric Mercer Quinn Snell Department of Computer Science Brigham Young University February 2013 Copyright c 2013 Sean Reque All Rights Reserved ABSTRACT An Optimized R5RS Macro Expander Sean Reque Department of Computer Science, BYU Master of Science Macro systems allow programmers abstractions over the syntax of a programming language. This gives the programmer some of the same power posessed by a programming language designer, namely, the ability to extend the programming language to fit the needs of the programmer. The value of such systems has been demonstrated by their continued adoption in more languages and platforms. However, several barriers to widespread adoption of macro systems still exist. The language Racket [6] defines a small core of primitive language constructs, including a powerful macro system, upon which all other features are built. Because of this design, many features of other programming languages can be implemented through libraries, keeping the core language simple without sacrificing power or flexibility. However, slow macro expansion remains a lingering problem in the language's primary implementation, and in fact macro expansion currently dominates compile times for Racket modules and programs. Besides the typical problems associated with slow compile times, such as slower testing feedback, increased mental disruption during the programming process, and unscalable build times for large projects, slow macro expansion carries its own unique problems, such as poorer performance for IDEs and other software analysis tools.
  • Towards a Portable and Mobile Scheme Interpreter

    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.
  • The Evolution of Lisp

    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.
  • Final Shift for Call/Cc: Direct Implementation of Shift and Reset

    Final Shift for Call/Cc: Direct Implementation of Shift and Reset

    Final Shift for Call/cc: Direct Implementation of Shift and Reset Martin Gasbichler Michael Sperber Universitat¨ Tubingen¨ fgasbichl,[email protected] Abstract JxKρ = λk:(k (ρ x)) 0 0 We present a direct implementation of the shift and reset con- Jλx:MKρ = λk:k (λv:λk :(JMK)(ρ[x 7! v]) k ) trol operators in the Scheme 48 system. The new implementation JE1 E2Kρ = λk:JE1Kρ (λ f :JE2Kρ (λa: f a k) improves upon the traditional technique of simulating shift and reset via call/cc. Typical applications of these operators exhibit Figure 1. Continuation semantics space savings and a significant overall performance gain. Our tech- nique is based upon the popular incremental stack/heap strategy for representing continuations. We present implementation details as well as some benchmark measurements for typical applications. this transformation has a direct counterpart as a semantic specifica- tion of the λ calculus; Figure 1 shows such a semantic specification for the bare λ calculus: each ρ is an environment mapping variables Categories and Subject Descriptors to values, and each k is a continuation—a function from values to values. An abstraction denotes a function from an environment to a D.3.3 [Programming Languages]: Language Constructs and Fea- function accepting an argument and a continuation. tures—Control structures In the context of the semantics, the rule for call/cc is this: General Terms Jcall=cc EKρ = λk:JEKρ (λ f : f (λv:λk0:k v) k) Languages, Performance Call=cc E evaluates E and calls the result f ; it then applies f to an Keywords escape function which discards the continuation k0 passed to it and replaces it by the continuation k of the call=cc expression.
  • 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
  • CLOS, Eiffel, and Sather: a Comparison

    CLOS, Eiffel, and Sather: a Comparison

    CLOS, Eiffel, and Sather: A Comparison Heinz W. Schmidt-, Stephen M. Omohundrot " September, 1991 li ____________T_R_._91_-0_47____________~ INTERNATIONAL COMPUTER SCIENCE INSTITUTE 1947 Center Street, Suite 600 Berkeley, California 94704-1105 CLOS, Eiffel, and Sather: A Comparison Heinz W. Schmidt-, Stephen M. Omohundrot September, 1991 Abstract The Common Lisp Object System defines a powerful and flexible type system that builds on more than fifteen years of experience with object-oriented programming. Most current implementations include a comfortable suite of Lisp support tools in­ cluding an Emacs Lisp editor, an interpreter, an incremental compiler, a debugger, and an inspector that together promote rapid prototyping and design. What else might one want from a system? We argue that static typing yields earlier error detec­ tion, greater robustness, and higher efficiency and that greater simplicity and more orthogonality in the language constructs leads to a shorter learning curve and more in­ tuitive programming. These elements can be found in Eiffel and a new object-oriented language, Sather, that we are developing at leS!. Language simplicity and static typ­ ing are not for free,·though. Programmers have to pay with loss of polymorphism and flexibility in prototyping. We give a short comparison of CLOS, Eiffel and Sather, addressing both language and environment issues. The different approaches taken by the languages described in this paper have evolved to fulfill different needs. While we have only touched on the essential differ­ ences, we hope that this discussion will be helpful in understanding the advantages and disadvantages of each language. -ICSI, on leave from: Inst. f. Systemtechnik, GMD, Germany tICSI 1 Introduction Common Lisp [25] was developed to consolidate the best ideas from a long line of Lisp systems and has become an important standard.
  • Towards a Portable and Mobile Scheme Interpreter

    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.
  • Published with the Approbation of the Board of Trustees

    Published with the Approbation of the Board of Trustees

    JOHNS HOPKINS UNIVERSITY CIRCULARS Published with the approbation of the Board of Trustees VOL. V.—No. 46.] BALTIMORE, JANUARY, 1886. [PRICE, 10 CENTS. RECENT PUBLICATIONS. Photograph of the Normal Solar Spectrum. Made Reproduction in Phototype of a Syriac Manuscript by PROFESSOR H. A. ROWLAND. (Baltimore, Johns Hopkins University, 1886). (Williams MS.) with the Antilegomena Epistles. Edited by IsAAC H. HALL. (Baltimore, Johns Hopkins University, 1886). [Froma letter to Science, New York, December 18, 1885]. The photographic map of the spectrum, upon which Professor Rowland [Froman article by I. H. Hall in the Journal of the Society of Biblical Literature and has expended so much hard work during the past three years, is nearly Exegesis for 1885, with additions]. ready for publication. The map is issued in a series of seven plates, cover- In September last (1884) I announced in The Independent the discovery ing the region from wave-length 3100 to 5790. Each plate is three feet of a manuscript of the Acts and Epistles, among which occur also the long and one foot wide, and contains two strips of the spectrum, except Epistles that were antilegomena among the Syrians; namely the Second plate No. 2, which contains three. Most of the plates are on a scalethree Epistle of Peter, the Second and Third Epistles of John, and the Epistle of times that of Angstrdm’s map, and in definition are more than equal to any Jude, in the version usually printed with our Peshitto New Testaments. It map yet published, at least to wave-length 5325. The 1474 line is widely is well known that the printed copies of these Epistles in that version all double, as also are b rest upon one manuscriptonly, in the Bodleian Library at Oxford, England, 3 and b4, while E may be recognized as double by the from which they were first published by Edward Pococke (Leyden, Elzevirs) expert.