The report gives a defining description of the programming language Scheme. Scheme is a statically scoped and properly tail recursive dialect of the Lisp programming language invented by Guy Lewis Steele Jr. and Gerald Jay Sussman. It was designed to have exceptionally clear and simple semantics and few different ways to form expressions. A wide variety of programming paradigms, including imperative, functional, and object-oriented styles, find convenient expression in Scheme. The introduction offers a brief history of the language and of the report. The first three chapters present the fundamental ideas of the language and describe the notational conventions used for describing the language and for writing programs in the language. Chapters 4 and 5 describe the syntax and semantics of expressions, definitions, programs, and libraries. Chapter 6 describes Scheme's built-in procedures, which include all of the language's data manipulation and input/output primitives. Chapter 7 provides a formal syntax for Scheme written in extended BNF, along with a formal denotational semantics. An example of the use of the language follows the formal syntax and semantics. Appendix A provides a list of the standard libraries and the identifiers that they export. Appendix B provides a list of optional but standardized implementation feature names. The report concludes with a list of references and an alphabetic index. Note: The editors of the R 5 RS and R 6 RS reports are listed as authors of this report in recognition of the substantial portions of this report that are copied directly from R 5 RS and R 6 RS. There is no intended implication that those editors, individually or collectively, support or do not support this report.

No abstract

No abstract

Partial evaluation can turn a general parser into a parser generator.The generated parsers surpass those produced by traditional parser generators in speed and compactness. We use an inherently functional approach to implement general LR(k) parsers and specialize them using the partial evaluatorSimilix.The functional implementation of LR parsing allows for concise implementation of the algorithms themselves and requires only straightforward changes to achieve good specialization results. In contrast, a traditional, stack-based implementation of a general LR parser requires significant structural chaflges to make it amenable to satisfactory specialization.

Partial evaluation can automatically generate program transformers .from interpreters. In the context of functional languages, we investigate the design space of higher-order interpreters to achieve certain transformation effects. Our work is based on the interpretive approach and exploits the language preservation property of offline partial evaluators.We have generated higher-order online partial evaluators, optimizing closure converters, and converters to first-order tail form. The latter can serve as the middle end of a compiler. The generated transformers are strictly more powerful than the partial evaluators used for their generation.

The combination of modern programming languages and partial evaluation yields new approaches to old problems. In particular, the combination of functional programming and partial evaluation can turn a general parser into a parser generator. We use an inherently functional approach to implement general LR(k) parsers and specialize them with respect to the input grammars using offline partial evaluation. The functional specification of LR parsing yields a concise implementation of the algorithms themselves. Furthermore, we demonstrate the elegance of the functional approach by incorporating on-the-fly attribute evaluation for S-attributed grammars and two schemes for error recovery, which lend themselves to natural and elegant implementation. The parsers require only minor changes to achieve good specialization results. The generated parsers have production quality and match those produced by traditional parser generators in speed and compactness.

While Emacs proponents largely agree that it is the world’s greatest text editor, it is almost as much a Lisp machine disguised as an editor. Indeed, one of its chief appeals is that it is programmable via its own programming language. Emacs Lisp is a Lisp in the classic tradition. In this article, we present the history of this language over its more than 30 years of evolution. Its core has remained remarkably stable since its inception in 1985, in large part to preserve compatibility with the many third-party packages providing a multitude of extensions. Still, Emacs Lisp has evolved and continues to do so. Important aspects of Emacs Lisp have been shaped by concrete requirements of the editor it supports as well as implementation constraints. These requirements led to the choice of a Lisp dialect as Emacs’s language in the first place, specifically its simplicity and dynamic nature: Loading additional Emacs packages or changing the ones in place occurs frequently, and having to restart the editor in order to re-compile or re-link the code would be unacceptable. Fulfilling this requirement in a more static language would have been difficult at best. One of Lisp’s chief characteristics is its malleability through its uniform syntax and the use of macros. This has allowed the language to evolve much more rapidly and substantively than the evolution of its core would suggest, by letting Emacs packages provide new surface syntax alongside new functions. In particular, Emacs Lisp can be customized to look much like Common Lisp, and additional packages provide multiple-dispatch object systems, legible regular expressions, programmable pattern-matching constructs, generalized variables, and more. Still, the core has also evolved, albeit slowly. Most notably, it acquired support for lexical scoping. The timeline of Emacs Lisp development is closely tied to the projects and people who have shaped it over the years: We document Emacs Lisp history through its predecessors, Mocklisp and MacLisp, its early development up to the “Emacs schism” and the fork of Lucid Emacs, the development of XEmacs, and the subsequent rennaissance of Emacs development.

No abstract