Results 1 -
6 of
6
Monad Transformers and Modular Interpreters
- In Proceedings of the 22nd ACM Symposium on Principles of Programming Languages. ACMPress
, 1995
"... We show how a set of building blocks can be used to construct programming language interpreters, and present implementations of such building blocks capable of supporting many commonly known features, including simple expressions, three different function call mechanisms (call-by-name, callby -value ..."
Abstract
-
Cited by 213 (10 self)
- Add to MetaCart
We show how a set of building blocks can be used to construct programming language interpreters, and present implementations of such building blocks capable of supporting many commonly known features, including simple expressions, three different function call mechanisms (call-by-name, callby -value and lazy evaluation), references and assignment, nondeterminism, first-class continuations, and program tracing. The underlying mechanism of our system is monad transformers, a simple form of abstraction for introducing a wide range of computational behaviors, such as state, I/O, continuations, and exceptions. Our work is significant in the following respects. First, we have succeeded in designing a fully modular interpreter based on monad transformers that includes features missing from Steele's, Espinosa's, and Wadler's earlier efforts. Second, we have found new ways to lift monad operations through monad transformers, in particular difficult cases not achieved in Moggi's original work. ...
Building Domain-Specific Embedded Languages
- ACM COMPUTING SURVEYS
, 1996
"... this paper I will describe the results of using the functional language Haskell to build DSELs. Haskell has several features that make it particularly suitable for this, but other languages could also be used. On the other hand, there are features that don't exist in any language (to my knowledge) t ..."
Abstract
-
Cited by 108 (4 self)
- Add to MetaCart
this paper I will describe the results of using the functional language Haskell to build DSELs. Haskell has several features that make it particularly suitable for this, but other languages could also be used. On the other hand, there are features that don't exist in any language (to my knowledge) that would make things even easier; there is much more work to be done.
Modular Domain Specific Languages and Tools
- in Proceedings of Fifth International Conference on Software Reuse
, 1998
"... A domain specific language (DSL) allows one to develop software for a particular application domain quickly and effectively, yielding programs that are easy to understand, reason about, and maintain. On the other hand, there may be a significant overhead in creating the infrastructure needed to supp ..."
Abstract
-
Cited by 95 (5 self)
- Add to MetaCart
A domain specific language (DSL) allows one to develop software for a particular application domain quickly and effectively, yielding programs that are easy to understand, reason about, and maintain. On the other hand, there may be a significant overhead in creating the infrastructure needed to support a DSL. To solve this problem, a methodology is described for building domain specific embedded languages (DSELs), in which a DSL is designed within an existing, higher-order and typed, programming language such as Haskell or ML. In addition, techniques are described for building modular interpreters and tools for DSELs. The resulting methodology facilitates reuse of syntax, semantics, implementation code, software tools, as well as look-and-feel.
Functional Programming with Overloading and Higher-Order Polymorphism
, 1995
"... The Hindley/Milner type system has been widely adopted as a basis for statically typed functional languages. One of the main reasons for this is that it provides an elegant compromise between flexibility, allowing a single value to be used in different ways, and practicality, freeing the progr ..."
Abstract
-
Cited by 64 (3 self)
- Add to MetaCart
The Hindley/Milner type system has been widely adopted as a basis for statically typed functional languages. One of the main reasons for this is that it provides an elegant compromise between flexibility, allowing a single value to be used in different ways, and practicality, freeing the programmer from the need to supply explicit type information. Focusing on practical applications rather than implementation or theoretical details, these notes examine a range of extensions that provide more flexible type systems while retaining many of the properties that have made the original Hindley/Milner system so popular. The topics discussed, some old, but most quite recent, include higher-order polymorphism and type and constructor class overloading. Particular emphasis is placed on the use of these features to promote modularity and reusability.
Modular Denotational Semantics for Compiler Construction
- In European Symposium on Programming
, 1996
"... . We show the benefits of applying modular monadic semantics to compiler construction. Modular monadic semantics allows us to define a language with a rich set of features from reusable building blocks, and use program transformation and equational reasoning to improve code. Compared to denotational ..."
Abstract
-
Cited by 52 (4 self)
- Add to MetaCart
. We show the benefits of applying modular monadic semantics to compiler construction. Modular monadic semantics allows us to define a language with a rich set of features from reusable building blocks, and use program transformation and equational reasoning to improve code. Compared to denotational semantics, reasoning in monadic style offers the added benefits of highly modularized proofs and more widely applicable results. To demonstrate, we present an axiomatization of environments, and use it to prove the correctness of a well-known compilation technique. The monadic approach also facilitates generating code in various target languages with different sets of built-in features. 1 Introduction We propose a modular semantics which allows language designers to add (or remove) programming language features without causing global changes to the existing specification, derive a compilation scheme from semantic descriptions, prove the correctness of program transformation and compilation...
Modular Monadic Semantics
"... Modular monadic semantics is a high-level and modular form of denotational semantics. It is capable of capturing individual programming language features as small building blocks which can be combined to form a programming language of arbitrary complexity. Interactions between features are isolated ..."
Abstract
- Add to MetaCart
Modular monadic semantics is a high-level and modular form of denotational semantics. It is capable of capturing individual programming language features as small building blocks which can be combined to form a programming language of arbitrary complexity. Interactions between features are isolated in such a way that the building blocks are invariant. This paper explores the theory and application of modular monadic semantics, including the building blocks for individual programming language features, equational reasoning with laws and axioms, modular proofs, program transformation, modular interpreters, and semantics-directed compilation. We demonstrate that modular monadic semantics makes programming languages easier to specify, reason about, and implement than the alternative of using conventional denotational semantics. Our contributions include: (a) the design of a fully modular interpreter based on monad transformers, including important features missing from several earlier efforts, (b) a method to lift monad operations through monad transformers, including difficult cases not achieved in earlier work, (c) a study of the semantic implications of the order of monad transformer composition, (d) a formal theory of modular monadic semantics that justifies our choice of liftings based on a notion of naturality, and (e) an implementation of our interpreter in Gofer, whose constructor classes provide just the added power over Haskell type classes to allow precise and convenient expression of our ideas. A note to reviewers: this paper is rather long. Short of resorting to “Part I / Part II”, the one way we see to shorten it would be to remove Section 4 and its Appendix B, which would amount to eliminating contribution (e) above. This would shorten the paper by about 12 pages.

