Proceedings of the 2014 Scheme and Functional Programming Workshop

PROCEEDINGS OF THE 2014 SCHEME AND FUNCTIONAL PROGRAMMING WORKSHOP Washington, DC, 19 November 2014 Edited by Jason Hemann Indiana University John Clements California Polytechnic State University 2015 Preface This volume contains the papers presented at Scheme '14, the 2014 Scheme and Functional Programming Workshop held on November 19, 2014 in Washington, DC. This year's workshop had more than 60 registered participants from insti- tutions throughout the United States and across the globe. For the second time this year's workshop was co-located with Clojure/conj. There were 13 submissions. Each submission was reviewed by at least 3 program committee members. The committee decided to accept 8 papers. Not in- cluded in these proceedings are the update on R7RS Working Group 2's progress by John Cowan, and Andy Wingo's keynote talk, What Scheme Can Learn from Javascript. Papers are listed by their order of presentation at the workshop. We would like to acknowledge the hard work of everyone who helped make Scheme '14 possible, including the administrative staff at Indiana University, the events management group at the Grand Hyatt Washington, the organizers of Clojure/conj, and the rest of our program committee. We would also like to thank Beckman Coulter, Cisco, and the Computer Science department at Indiana University for their sponsorship. September 11, 2015 Jason Hemann Bloomington, Indiana John Clements v Table of Contents Implementing R7RS on R6RS Scheme system :::::::::::::::::::::::: 1 Takashi Kato Code Versioning and Extremely Lazy Compilation of Scheme ::::::::::: 2 Baptiste Saleil and Marc Feeley Microscheme: Functional programming for the Arduino :::::::::::::::: 3 Ryan Suchocki and Sara Kalvala Structure Vectors and their Implementation :::::::::::::::::::::::::: 4 Benjamin Cérat and Marc Feeley A Linear Encoding of Pushdown Control-Flow Analysis :::::::::::::::: 5 Steven Lyde, Thomas Gilray and Matthew Might Concrete and Abstract Interpretation: Better Together :::::::::::::::: 6 Maria Jenkins, Leif Andersen, Thomas Gilray and Matthew Might Little Languages for Relational Programming ::::::::::::::::::::::::: 7 Daniel Brady, Jason Hemann and Daniel P. Friedman Meta-Meta-Programming: Generating C++ Template Metaprograms with Racket Macros ::::::::::::::::::::::::::::::::::::::::::::::: 8 Michael Ballantyne, Chris Earl and Matthew Might vi Program Committee Michael D. Adams University of Illinois at Urbana-Champaign William Byrd University of Utah Stephen Chang Northeastern University John Clements California Polytechnic State University Christopher Earl University of Utah Kathryn E. Gray University of Cambridge Jason Hemann Indiana University Felix S. Klock II Northeastern University Norman Ramsey Tufts University Paul Stansifer Northeastern University Paul Steckler San Jose, CA Mitchell Wand Northeastern University vii Implementing R7RS on an R6RS Scheme system Takashi Kato Bell ID B.V. [email protected] Abstract The search result may contain implementations themselves and The Scheme language has three major standards; Revised5 Re- may not contain repositories which do not have the keywords in port on the Algorithmic language Scheme (R5RS) standardised their description or searchable locations. So these are not accurate in February 1998, the Revised6 Report on Algorithmic language numbers of repositories that provide libraries. However, it has only Scheme (R6RS) standardised in September 2007 and the Revised7 been one year since R7RS standardised so we can expect the num- Report on the Algorithmic language Scheme (R7RS) standardised bers of R7RS repositories to grow in near future. We have con- cluded that it is important to support the R7RS on our Scheme sys- in July 2013. R7RS, the latest standard of Scheme focuses on the 1 R5RS compatibility thus making R5RS implementations compli- tem, Sagittarius which base is R6RS, so that it would be beneficial ant with it would not be so difficult. For R6RS implementations it for future Scheme users. One of our goals is using R6RS libraries would be much more difficult; R7RS clearly says it is not a suc- in R7RS library form and vice versa. The following sections de- cessor of the R6RS. This paper describes the major differences be- scribe how we implemented the R7RS on top of the R6RS Scheme tween these two Scheme standards and how we made our Scheme system and how both R6RS and R7RS libraries can inter-operate. system, Sagittarius, compliant with both R6RS and R7RS, and made it able to use both standards’ libraries seamlessly. 2. Incompatibilities R7RS lists numerous incompatibilities with R6RS. However, in- Keywords Scheme, R6RS, R7RS compatibilities of procedures or macros are negligible because both R6RS and R7RS support renaming import and export. So 1. Introduction we only need to define them for R7RS libraries. For example, 6 the R6RS let-syntax must be sliced into begin however The Revised Report on Algorithmic language Scheme (R6RS) [2] the R7RS one must create a scope. If an implementation has the was completed in September 2007 with many new improvements R6RS style let-syntax, then it is easy to implement the R7RS and a focus on portability. Some implementations were adopted for style one with it. A possible implementation of the R7RS style R6RS. Some R6RS compliant implementations were created. In let-syntax would look something like the following: July 2013, The Revised7 Report on Algorithmic language Scheme 5 (R7RS) [3] was completed with the focus on the Revised Report Listing 1: R7RS style let-syntax on Algorithmic language Scheme (R5RS) [1] compatibility. Both R6RS and R7RS are R5RS compatible, however these two stan- ;; R7RS style let-syntax dards are not totally compatible. Therefore, these two standards are (import not able to share libraries nor scripts. (rename (rnrs) We have searched repositories on GitHub and Google Code with (let-syntax r6rs:let-syntax))) keyword “R6RS” and “R7RS”, and repository language “Scheme” (define-syntax let-syntax in August 2014. On GitHub, there were 59 repositories related to (syntax-rules () R6RS and 12 repositories related to R7RS. On Google Code, there ((_ ((vars trans) ...) expr ...) were 18 repositories related to R6RS and 8 repositories related to (r6rs:let-syntax ((vars trans) ...) R7RS. (let () expr ...))))) Thus, the incompatibilities we need to discuss here are the lay- Table 1: Number of Repositories ers that require deeper support of implementations such as library Keyword GitHub Google Code forms and lexical notations. R6RS 59 18 R7RS 12 8 2.1 Library forms A library or module system is essential for modern programming languages to allow programmers to reuse useful programs. How- ever, the Scheme language did not provide this until the R6RS was standardised. R6RS decided to call it a library system so we also call it library system here. From Scheme language perspective, it is quite a new concept. R7RS has also been standardised with a library system however it does not have the same form as the R6RS. The R6RS has library keyword for library system whilst the R7RS has define-library. The R6RS does not define [Copyright notice will appear here once ’preprint’ option is removed.] 1 Sagittarius Scheme: https://bitbucket.org/ktakashi/sagittarius-scheme/ 1 2014/11/7 mechanism to absorb incompatibilities between implementations ((library (bar)) nor to check whether required libraries exist. Thus making a (import (bar))) portable library requires using unwritten rules. The library sys- (sagittarius tem of the R7RS, on the other hand, does have the feature provided (import (sagittarius)) by cond-expand keyword. (define bar To demonstrate the difference between R6RS and R7RS library implementation-dependent-procedure)) forms, we show concrete examples of both. The library foo ex- (else ports the variable bar and requires an implementation dependent (error "unsupported implementation"))) procedure. (export bar)) 2.1.1 R6RS library An R7RS library name can contain symbols and numbers, and The R6RS library system has rather fixed form. With the R6RS does not support library version references. Thus, (srfi 1) is library form, the library (foo) would look like the following: a valid library name whilst the R6RS one needs to be written something like (srfi :1). Listing 2: R6RS library form Moreover, unlike the R6RS library form, R7RS supports more keywords, import, export, cond-expand, include, (library (foo) include-ci and include-library-declarations. Us- (export bar) ing cond-expand makes the R7RS library system enables writ- (import (rnrs) (compat foo)) ing implementation-dependent code without separating library (define bar (compat-foo-proc))) files. The above example does not show, however, using include or An R6RS library name can only contain symbols and a version 2 include-ci, which enable including files from outside of the file reference at the end of library name , which must be a list of where libraries are defined. And include-library-declarations numbers. Both export and import forms must be present only includes files containing library declarations. once in respective order. Here, the (compat foo) is a compatible layer of an 2.1.3 Export form implementation-dependent procedure. R6RS does not have the Besides those overall differences, the R6RS and R7RS have slightly means to load implementation-specific code, however, there is a different syntax for the rename clause of export forms. The de-facto standard supported by most of the R6RS implementations R6RS export may have multiple renamed exporting identifiers

Load more