Revised6 Report on the Algorithmic Language Scheme

Sperber, Michael; Dybvig, R. Kent; Flatt, Matthew; straaten, Anton Van; Findler, Robby; Matthews, Jacob

doi:10.1017/s0956796809990074

Cited by 74 publications

(66 citation statements)

References 20 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…report supersedes the revisedS report [13,33,46,50,52,53]? Or perhaps each semantics specifies one particular facet, however large that facet may be, of Scheme, irrespective of others?…”

Section: ¥ T Umentioning

confidence: 88%

Towards Compatible and Interderivable Semantic Specifications for the Scheme Programming Language, Part I: Denotational Semantics, Natural Semantics, and Abstract Machines

Danvy

2009

Semantics and Algebraic Specification

View full text Add to dashboard Cite

We derive two big-step abstract machines, a natural semantics, and the valuation function of a denotational semantics based on the small-step abstract machine for Core Scheme presented by Clinger at PLDI'98. Starting from a functional implementation of this small-step abstract machine, (1) we fuse its transition function with its driver loop, obtaining the functional implementation of a big-step abstract machine; (2) we adjust this big-step abstract machine so that it is in defunctionalized form, obtaining the functional implementation of a second big-step abstract machine; (3) we refunctionalize this adjusted abstract machine, obtaining the functional implementation of a natural semantics in continuation style; and (4) we closure-unconvert this natural semantics, obtaining a compositional continuation-passing evaluation function which we identify as the functional implementation of a denotational semantics in continuation style. We then compare this valuation function with that of Clinger's original denotational semantics of Scheme.

show abstract

“…report supersedes the revisedS report [13,33,46,50,52,53]? Or perhaps each semantics specifies one particular facet, however large that facet may be, of Scheme, irrespective of others?…”

Section: ¥ T Umentioning

confidence: 88%

Towards Compatible and Interderivable Semantic Specifications for the Scheme Programming Language, Part I: Denotational Semantics, Natural Semantics, and Abstract Machines

Danvy

2009

Semantics and Algebraic Specification

View full text Add to dashboard Cite

show abstract

“…Lisp [20] has a simple syntax that translates directly to data values, which can then be manipulated and executed. Scheme [9,11,29] and Racket [16][17][18] refine Lisp's technique by separating code from data and using that separation to provide additional features like "hygienic" handling of bindings. Tcl [24] allows the programmer to mark a given code block as uninterpreted, which reifies it as a string that can be manipulated and then interpreted as code at run time.…”

Section: Related Workmentioning

confidence: 99%

Contracts for domain-specific languages in Ruby

2014

View full text Add to dashboard Cite

This paper concerns object-oriented embedded DSLs, which are popular in the Ruby community but have received little attention in the research literature. Ruby DSLs implement language keywords as implicit method calls to self; language structure is enforced by adjusting which object is bound to self in different scopes. While Ruby DSLs are powerful and elegant, they suffer from a lack of specification. In this paper, we introduce contracts for Ruby DSLs, which allow us to attribute blame appropriately when there are inconsistencies between an implementation and client. We formalize Ruby DSL contract checking in DSL, a core calculus that uses premethods with instance evaluation to enforce contracts. We then describe RDL, an implementation of Ruby DSL contracts. Finally, we present two tools that automatically infer RDL contracts: TypeInfer infers simple, type-like contracts based on observed method calls, and DSLInfer infers DSL keyword scopes and nesting by generating and testing candidate DSL usages based on initial examples. The type contracts generated by TypeInfer work well enough, though they are limited in precision by the small number of tests, while DSLInfer finds almost all DSL structure. Our goal is to help users understand a DSL from example programs.

show abstract

“…PLT Scheme extends the Scheme programming language [43] with a class system. In this section, we briefly describe this class system; for details, we refer the interested reader to a tutorial paper [16].…”

Section: First-class Classes In Plt Schemementioning

confidence: 99%

Contracts for First-Class Classes

Strickland

Dimoulas

Takikawa

et al. 2013

ACM Trans. Program. Lang. Syst.

View full text Add to dashboard Cite

First-class classes add expressive power to class-based objectoriented languages. Most importantly, programmers can abstract over common scenarios with first-class classes. The addition of behavioral software contracts to a language with first-class classes poses significant challenges, however. In this paper, we present the first contract system for a programming language with first-class classes. The design has been implemented for PLT Scheme, which supports first-class classes and which implements mixins and traits as syntactic sugar. We therefore expect that our experience is also useful for languages with native mixins and/or traits. First-class Classes and ContractsOver the past couple of decades, programming language designers have repeatedly demonstrated the usefulness of operations on classes. For example, Bracha and Cook [7] distilled and formalized the Flavors notion of mixins 1 [37]. Roughly speaking, mixins in a single-inheritance language are functions from classes to classes, adding fields and methods to the given class. Since then mixins have been the subject of numerous studies [1,3,9,17,33] [29,41], and PLT Scheme [15] take the final step and turn classes into first-class values. In such a world, the evaluation of an expression may produce a class. Methods or functions may consume and produce classes. Classes may store classes in fields. And most importantly, the super-class designator in a class is just an expression, meaning the super-class is computed at runtime. Equipped with this power, a programmer can add mixins and traits as "syntactic sugar" [16] but even better, a programmer can explore entirely new ways of organizing class-based programs.PLT Scheme, like Eiffel [36] and many other object-oriented languages [5, 8, 21-24, 26, 31, 32, 36, 40], also comes with a contract system. A contract [6] is a logical assertion that governs the flow of values between distinct components. The compiler and the run-time system cooperate to monitor contracts so that they can issue an informative report when values fail to respect a contract. In PLT Scheme, a report on a contract violator both explains the nature of the violation and pinpoints the violator.Extending contracts to first-class classes poses significant challenges. First, it demands a language for specifying contracts for 1 The concept of mixins first appeared in H. I. Cannon's 1979 unpublished paper "Flavors: A non-hierarchical approach to object-oriented programming," an MIT technical report in draft.classes as values. Second, when classes are first-class values, their separate roles as sources of new objects and as containers for reusable code requires rather different forms of specification than those of Eiffel [36] or even something as general as JML [27]. Third, adding contracts to first-class classes demands an implementation strategy that affects the performance of classes without contracts. Finally, PLT Scheme in particular also mixes conventional inheritance and Beta-style inheritance, complicating the addition of contracts...

show abstract

Revised6 Report on the Algorithmic Language Scheme

Cited by 74 publications

References 20 publications

Towards Compatible and Interderivable Semantic Specifications for the Scheme Programming Language, Part I: Denotational Semantics, Natural Semantics, and Abstract Machines

Towards Compatible and Interderivable Semantic Specifications for the Scheme Programming Language, Part I: Denotational Semantics, Natural Semantics, and Abstract Machines

Contracts for domain-specific languages in Ruby

Contracts for First-Class Classes

Contact Info

Product

Resources

About