In this paper we describe the promoted tyft/tyxt rule format for defining higher-order languages. The rule format is a generalization of Groote and Vaandrager 's tyft/tyxt format in which terms are allowed as labels on transitions in rules. We prove that bisimulation is a congruence for any language defined in promoted tyft/tyxt format and demonstrate the usefulness of the rule format by presenting promoted tyft/tyxt definitions for the lazy -calculus, CHOCS and the ß-calculus. 1 Introduction For a programming language definition that uses bisimulation as the notion of equivalence, it is desirable for the bisimulation relation to be compatible with the language constructs; i.e. that bisimulation be a congruence. Several rule formats have been defined, so that as long as a definition satisfies certain syntactic constraints, then the defined bisimulation relation is guaranteed to be a congruence. However these rule formats have not been widely used for defining languages with higher-...

Concurrent programs require high-level abstractions in order to manage complexity and enable compositional reasoning. In this paper, we introduce a novel concurrency abstraction, dubbed transactional events, which combines first-class synchronous message passing events with all-or-nothing transactions. This combination enables simple solutions to interesting problems in concurrent programming. For example, guarded synchronous receive can be implemented as an abstract transactional event, whereas in other languages it requires a non-abstract, non-modular protocol. As another example, three-way rendezvous can be implemented as an abstract transactional event, which is impossible using first-class events alone. Both solutions are easy to code and easy to reason about. The expressive power of transactional events arises from a sequencing combinator whose semantics enforces an all-or-nothing transactional property – either both of the constituent events synchronize in sequence or neither of them synchronizes. This sequencing combinator, along with a non-deterministic choice combinator, gives transactional events the compositional structure of a monad-with-plus. We provide a formal semantics for transactional events and give a detailed account of an implementation.

This paper presents two typed higher-order concurrent functional programming languages, based on Reppy's Concurrent ML. The first is a simplified, monomorphic variant of CML, which allows reduction of terms of any type. The second uses an explicit type constructor for computation, in the style of Moggi's monadic metalanguage. Each of these languages is given an operational semantics, which can be used as the basis of bisimulation equivalence. We show how Moggi's translation of the call-by-value lambdacalculus into the mondadic metalanguage can be extended to these concurrent languages, and that this translation is correct up to weak bisimulation. 1 Introduction Reppy's (1991, 1992) Concurrent ML is an extension of New Jersey ML with features for spawning threads, which can communicate by one-to-one synchronous handshake in the style of Milner's (1989) CCS. There are (at least) two approaches to giving the operational semantics to CML. The `functional language definition' tradition (Mi...

Although there is a large body of literature on formal definitions of programming languages, relatively little work has been done in applying formal techniques to defining debuggers. Natural operational semantics, denotational semantics and transitional operational semantics are all proven techniques for formally defining programming languages. In this paper we present techniques for formally defining debuggers based on each of these three styles of definitions. We will investigate each style of definition by demonstrating how a simple debugger might be defined in each framework. 1 Introduction According to a traditional view, a debugger is a tool that allows a programmer to get information about a program by observing the evaluation of the program according to the implementation. From a more general perspective, a debugger can be viewed as a tool that allows the programmer to gain additional insight into a program by observing the behavior of the program according to some well...