DOCSLIB.ORG

Keyword and Optional Arguments in PLT Scheme

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read 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. right vehicle for parameterizing code with respect to a few run-time In a procedure declaration, a formal argument can be paired values. For parameterization over larger sets of values, however, with a default-value expression using a set of parentheses—or, Scheme procedures quickly become inconvenient. by convention, square brackets. The notation for a default-value Keyword and optional arguments support tasks that need more expression is the same whether the argument is by-position or by- arguments than fit comfortably into procedures, but where radia- keyword. For example, a rectangle’s height might default to its cally different forms—such as unit or class in PLT Scheme— width and its color default to pink: are too heavyweight conceptually and notationally. At the same time, keyword and optional arguments offer a smooth extension (define (rectangle width path for existing procedure-based APIs. Keyword arguments can [height width] be added to a procedure to extend its functionality without bind- #:color [color "pink"]) ing a new identifier (which always carries the danger of colliding ....) with other bindings) and in a way that composes with other such This revised rectangle procedure could be called in any of the extensions. following ways: Keyword arguments in PLT Scheme are supported through a (rectangle 10) straightforward extension of the lambda, define, and applica- (rectangle 10 20) tion forms. Lexically, a keyword starts with #: and continues in the (rectangle 10 20 #:color "blue") same way as an identifier; for example, #:color is a keyword.1 (rectangle 10 #:color "blue") A keyword is associated with a formal or actual argument by (rectangle #:color "blue" 10 20) placing the keyword before the argument name or expression. For (rectangle #:color "blue" 10) example, a rectangle procedure that accepts two by-position (rectangle 10 #:color "blue" 20) arguments and one argument with the #:color keyword can be Our goals in a design for keyword and optional arguments written as include providing especially clear error messages and enforcing a consistent syntax for keyword arguments. Toward these goals, two 1 See Section 7.7 for a discussion on this choice of keyword syntax. aspects of our design set it apart from previous approaches in Lisp and Scheme: • Keywords are distinct from symbols, and they are not self- quoting as expressions. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed For example, the form for profit or commercial advantage and that copies bear this notice and the full citation #:color on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. in an expression position is a syntax error, while 2009 Workshop on Scheme and Functional Programming (rectangle #:color "blue") 1 is a call to rectangle with the #:color argument "blue". (lambda hkw-formalsi hbodyi ...+) In the latter case, the procedure-application form treats the #:color keyword as an argument tag, and not as an expres- hkw-formalsi = (hformal-argi ...) sion. Every keyword in an application must be followed by a | (hformal-argi ...+ . hrest-idi) value expression, so the form | hrest-idi (rectangle #:color #:filled? #f) hformal-argi = hidi is rejected as a syntax error, because #:color lacks an ar- | [hidi hdefault-expri] gument expression; if keywords could be expressions, the call | hkeywordi hidi would be ambiguous, because #:filled? might be intended | hkeywordi [hidi hdefault-expri] as the #:color argument to rectangle. ... means “zero or more,” ...+ means “one or more,” hidi or hrest-idi • Keywords are not passed as normal arguments to arbitrary pro- matches an identifier, hexpri or hdefault-expri matches an expression, cedures, where they might be confused with regular procedure hkeywordi matches a keyword, and hbodyi matches a definition or arguments. Instead, a different calling convention is used for expression in an internal-definition context keyword arguments. For example, Figure 1: Extended grammar for lambda (cons #:color "blue") does not create a pair whose first element is a keyword and (hproc-expri hactual-argi ...+) second element is a string. Evaluating this expression instead hactual-argi = hexpri reports a run-time error that cons does not expect keyword | hkeywordi hexpri arguments. Although a keyword is not self-quoting as an expression, a Figure 2: Extended grammar for procedure application keyword is a first-class value in PLT Scheme. A keyword can be quoted to produce a valid expression, as in ’#:color and (cons ’#:color "blue"), where the latter creates a pair whose first > (define polygon element is a keyword. Keyword values and quoted-keyword expres- (lambda (n [side-len (/ 12 n)] . options) sions are useful for creating a procedure that accepts arbitrary key- (list n side-len options))) word arguments and processes them explicitly. Keyword values are > (polygon) also useful in reflective operations that inspect the keyword require- procedure polygon: no clause matching 0 arguments ments of a procedure. By convention, PLT Scheme programmers > (polygon 3) do not use keywords for run-time enumerations and flags, leaving (3 4 ()) those roles to symbols and reserving keywords for syntactic roles. > (polygon 3 7) (3 7 ()) The rest of the paper proceeds as follows. Section 2 describes > (polygon 3 7 ’solid ’smooth) the syntax and semantics of keyword and optional arguments in (3 7 (solid smooth)) PLT Scheme. Section 4 describes our implementation of keyword arguments. Section 5 provides some information on the perfor- When the hkeywordi hidi or hkeywordi [hidi hdefault-expri] mance of keyword and optional arguments. Section 6 reports on forms of hformal-argi are used to construct a lambda expres- our experience using keywords in PLT Scheme. Section 7 describes sion, the resulting procedure accepts keyword-tagged arguments previous designs for keywords in Lisp and Scheme and relates them in addition to the arguments that would be accepted without the to our design. keyword-tagged arguments. Arguments using the hkeywordi hidi form are required, while arguments using the hkeywordi [hidi hdefault-expri] form are optional. As with the keywordless [hidi 2. Syntax and Semantics hdefault-expri] form, each keyword-tagged hdefault-expri is eval- Figure 1 shows the full syntax of PLT Scheme’s lambda. In a uated for a given application of the procedure if no actual argument hkw-formalsi, all hidis must be distinct, including hrest-idi, and is tagged with the corresponding hkeywordi, and the preceding ar- all hkeywordis must be distinct. A required non-keyword argument gument hidis are in the environment of each hdefault-expri. When (i.e., the first case of hformal-argi) must not follow an optional non- hdefault-expris are evaluated for multiple arguments, they are eval- keyword argument (i.e., the second case of hformal-argi). uated in the order declared in the lambda expression, independent A lambda form that is constructed using only the hidi form of of whether the arguments have a keyword tag or the order of key- hfomal-argi has the same meaning as in standard Scheme (Sperber word tags on actual arguments. Actual arguments that are tagged 2007). A lambda form that uses only the hidi and [hidi hdefault- with a keyword can be supplied in any order with respect to each expri] forms of hformal-argi can be converted to an equivalent other and with respect to by-position arguments. case-lambda form; the appendix shows the conversion pre- > (define polygon cisely in terms of syntax-rules. For each optional argument (lambda (n [side-len (/ 12 n)] that is not supplied in an application of the procedure,
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]
  • 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]
  • The Adventures of a Pythonista in Schemeland Release 0.1
    The Adventures of a Pythonista in Schemeland Release 0.1 Michele Simionato August 05, 2009 CONTENTS 1 A bit of history3 1.1 My target.....................................3 1.2 A bit of history: Fortran and Lisp........................4 1.3 The algorithmic language Scheme........................5 2 About Scheme implementations7 2.1 About Scheme implementations.........................7 2.2 About the library problem............................8 2.3 Additional difficulties.............................. 10 3 Of parentheses and indentation 13 3.1 Of parens and indentation............................ 13 3.2 About the prefix syntax............................. 15 4 Scheme bibliography (and a first program) 17 4.1 Scheme resources for beginners......................... 17 4.2 A simple Scheme program............................ 18 5 About tail call optimization (and the module system) 21 5.1 There are no for loops in Scheme....................... 21 5.2 There is no portable module system....................... 23 5.3 A simple benchmark............................... 25 6 The danger of benchmarks 29 6.1 Beware of wasted cycles............................. 29 6.2 Beware of cheats................................. 31 6.3 Beware of naive optimization.......................... 32 6.4 Recursion vs iteration.............................. 33 7 Symbols and lists 35 7.1 Symbols..................................... 35 7.2 Lists....................................... 37 7.3 Some example.................................. 38 8 Quoting and quasi-quoting 41 8.1 Quoting.....................................
    [Show full text]