Reusable Components of Semantic Specifications

Abstract

Abstract. Semantic specifications of programming languages typically have poor modularity. This hinders reuse of parts of the semantics of one language when specifying a different language -even when the two languages have many constructs in common -and evolution of a language may require major reformulation of its semantics. Such drawbacks have discouraged language developers from using formal semantics to document their designs. In the PLanCompS project, we have developed a component-based approach to semantics. Here, we explain its modularity aspects, and present an illustrative case study: a component-based semantics for Caml Light. We have tested the correctness of the semantics by running programs on an interpreter generated from the semantics, comparing the output with that produced on the standard implementation of the language. Our approach provides good modularity, facilitates reuse, and should support co-evolution of languages and their formal semantics. It could be particularly useful in connection with domain-specific languages and language-driven software development.

A Component-Based Formal Language Workbench

“…We start by briefly recalling the main features of the CBS framework for component-based specification. For more detailed expositions, see [5,7,10,15].…”

A Modular Structural Operational Semantics for Delimited Continuations

“…To demonstrate the specification of control operators using I-MSOS rules, this paper will use the funcon framework [8]. This framework contains an open collection of modular fundamental constructs (funcons), each of which has its semantics specified independently by I-MSOS rules.…”

“…However, this paper is not concerned with the translation of control operators from any specific language: our aim is to give MSOS specifications of control operators, and the funcon framework is a convenient environment for specifying prototypical control operators. Examples of translations into funcons can be found in [8,28].…”

“…When we come to funcons for control operators, we will continue to use italic when referring to the control operator in general, and bold when referring to the funcon specifically. Figure 1 presents I-MSOS rules for the exception-handling funcons throw and catch [8]. The idea is that throw emits an exception signal, and catch detects and handles that signal.…”

“…While it is known that MSOS can specify the semantics of programming constructs for exception handling [7,8,25], it has been unclear whether MSOS can specify more complex control-flow operators, such as call/cc [1,9]. Indeed, the perceived difficulty of handling control operators has been regarded as one of the main limitations of MSOS relative to other modular semantic frameworks (e.g.…”