Results 1 - 10
of
16
Understanding and Evolving the ML Module System
, 2005
"... 9706572, and the US Air Force under grant F19628-95-C-0050 and a generous fellowship. The views and conclusions contained in this document are those of the author and should not be interpreted as representing the official policies, either expressed or implied, of any sponsoring institution, the U.S. ..."
Abstract
-
Cited by 36 (10 self)
- Add to MetaCart
9706572, and the US Air Force under grant F19628-95-C-0050 and a generous fellowship. The views and conclusions contained in this document are those of the author and should not be interpreted as representing the official policies, either expressed or implied, of any sponsoring institution, the U.S. government or any other entity.
An abstract monadic semantics for value recursion
- In Proceeding of the 2003 Workshop on Fixed Points in Computer Science (FICS
, 2003
"... This paper proposes an operational semantics for value recursion in the context of monadic metalanguages. Our technique for combining value recursion with computational effects works uniformly for all monads. The operational nature of our approach is related to the implementation of recursion in Sch ..."
Abstract
-
Cited by 17 (6 self)
- Add to MetaCart
This paper proposes an operational semantics for value recursion in the context of monadic metalanguages. Our technique for combining value recursion with computational effects works uniformly for all monads. The operational nature of our approach is related to the implementation of recursion in Scheme and its monadic version proposed by Friedman and Sabry, but it defines a different semantics and does not rely on assignments. When contrasted to the axiomatic approach proposed by Erkök and Launchbury, our semantics for the continuation monad invalidates one of the axioms, adding to the evidence that this axiom is problematic in the presence of continuations. 1
Call-by-value mixin modules: Reduction semantics, side effects, types
- Programming Languages & Systems, 13th European Symp. Programming
, 2004
"... Mixin modules are a framework for modular programming that supports code parameterization, incremental programming via late binding and redefinitions, and cross-module recursion. In this paper, we develop a language of mixin modules that supports call-by-value evaluation, and formalize a reduction ..."
Abstract
-
Cited by 14 (4 self)
- Add to MetaCart
Mixin modules are a framework for modular programming that supports code parameterization, incremental programming via late binding and redefinitions, and cross-module recursion. In this paper, we develop a language of mixin modules that supports call-by-value evaluation, and formalize a reduction semantics and a sound type system for this language.
Recursive Modules for Programming
- In Proc. ICFP’06
, 2006
"... The ML module system is useful for building large-scale programs. The programmer can factor programs into nested and parameterized modules, and can control abstraction with signatures. Yet ML prohibits recursion between modules. As a result of this constraint, the programmer may have to consolidate ..."
Abstract
-
Cited by 12 (8 self)
- Add to MetaCart
The ML module system is useful for building large-scale programs. The programmer can factor programs into nested and parameterized modules, and can control abstraction with signatures. Yet ML prohibits recursion between modules. As a result of this constraint, the programmer may have to consolidate conceptually separate components into a single module, intruding on modular programming. Introducing recursive modules is a natural way out of this predicament. Existing proposals, however, vary in expressiveness and verbosity. In this paper, we propose a type system for recursive modules, which can infer their signatures. Opaque signatures can also be given explicitly, to provide type abstraction either inside or outside the recursion. The type system is provably decidable, and is sound for a call-by-value semantics. We also gives a solution to the expression problem, in support of our design choices. 1 1
Mixin’ Up the ML Module System
"... ML modules provide hierarchical namespace management, as well as fine-grained control over the propagation of type information, but they do not allow modules to be broken up into separately compilable, mutually recursive components. Mixin modules facilitate recursive linking of separately compiled c ..."
Abstract
-
Cited by 8 (3 self)
- Add to MetaCart
ML modules provide hierarchical namespace management, as well as fine-grained control over the propagation of type information, but they do not allow modules to be broken up into separately compilable, mutually recursive components. Mixin modules facilitate recursive linking of separately compiled components, but they are not hierarchically composable and typically do not support type abstraction. We synthesize the complementary advantages of these two mechanisms in a novel module system design we call MixML. A MixML module is like an ML structure in which some of the components are specified but not defined. In other words, it unifies the ML structure and signature languages into one. MixML seamlessly integrates hierarchical composition, translucent ML-style data abstraction, and mixin-style recursive linking. Moreover, the design of MixML is clean and minimalist; it emphasizes how all the salient, semantically interesting features of the ML module system (as well as several proposed extensions to it) can be understood simply as stylized uses of a small set of orthogonal underlying constructs, with mixin composition playing a central role.
Recursive object-oriented modules
- In Proc. FOOL 12
, 2005
"... Abstract. Classes and ML-style modules are complementary. The former are better at extension, the latter at abstraction. We propose an object-oriented calculus based on a nominal module system with mutual recursion. Our calculus is kept simple by using the same construct for modules, functors, signa ..."
Abstract
-
Cited by 4 (3 self)
- Add to MetaCart
Abstract. Classes and ML-style modules are complementary. The former are better at extension, the latter at abstraction. We propose an object-oriented calculus based on a nominal module system with mutual recursion. Our calculus is kept simple by using the same construct for modules, functors, signatures and classes. Static guarantee of safety properties turns out to be a non trivial problem in this system, as cyclic dependencies might exist. We define a decidable type system, which ensures that module definitions are well-founded, and a call-by-value semantics, for which type soundness is proved. 1
Extended recursive definitions in call-by-value languages, with applications to mixin modules and recursive modules
- in "Electronic proceedings of the second APPSEM II Workshop
, 2004
"... and recursive modules ..."
Path resolution for recursive modules
, 2006
"... The ML module system enables flexible development of large software systems by its support of nested structures, functors and signatures. In spite of this flexibility, however, recursion between modules is prohibited, since dependencies between modules must accord with the order of definitions. As a ..."
Abstract
-
Cited by 1 (1 self)
- Add to MetaCart
The ML module system enables flexible development of large software systems by its support of nested structures, functors and signatures. In spite of this flexibility, however, recursion between modules is prohibited, since dependencies between modules must accord with the order of definitions. As a result of this constraint, programmers may have to consolidate conceptually separate components into a single module, intruding on modular programming. Recently much work has been devoted to extending the module system with recursion, and developing a type system for recursive modules is one of the main subjects of study. Since recursion is an essential mechanism, one is to face several non-trivial issues to be considered for designing a practical type system. Our goal is to make recursive modules an ordinary construct of the module language for ML programmers. We want to use them easily in everyday programming, possibly combining with other constructs of the core and the module languages. With this goal, we are to develop a type system for recursive modules, which is practical and useful from the programmer’s perspective. In this paper, we present a decidable type system which can reconstruct the necessary type information during type checking of recursive modules. In particular, we develop algorithms for resolving forward references in recursive modules, by confining ourselves to first-order functors. The type system is provably sound for a call-by-value operational semantics. 1 1
A Programming Language for Probabilistic Computation
, 2005
"... As probabilistic computations play an increasing role in solving various problems, researchers have designed probabilistic languages to facilitate their modeling. Most of the existing probabilistic languages, however, focus only on discrete distributions, and there has been little effort to develop ..."
Abstract
-
Cited by 1 (0 self)
- Add to MetaCart
As probabilistic computations play an increasing role in solving various problems, researchers have designed probabilistic languages to facilitate their modeling. Most of the existing probabilistic languages, however, focus only on discrete distributions, and there has been little effort to develop probabilistic languages whose expressive power is beyond discrete distributions. This dissertation presents a probabilistic language, called PTP (ProbabilisTic Programming), which supports all kinds of probability distributions.
An Alternative Approach to Initializing Mutually Referential Objects
, 2005
"... Mutual dependencies between objects arise frequently in programs, and programmers must typically resort to manually filling “initialization holes ” to help construct the corresponding object graphs, i.e. null values and/or explicitly mutable locations. This report describes a “base-line ” proposal f ..."
Abstract
-
Cited by 1 (0 self)
- Add to MetaCart
Mutual dependencies between objects arise frequently in programs, and programmers must typically resort to manually filling “initialization holes ” to help construct the corresponding object graphs, i.e. null values and/or explicitly mutable locations. This report describes a “base-line ” proposal for a generalized form of value recursion in an ML-like language called initialization graphs, where value recursion is given the simplistic semantics of a graph of lazy computations whose nodes are sequentially forced, with uses of recursive values checked for initialization-soundness at runtime. We then develop examples using this mechanism to show how problematic the issue of value recursion is for ML-like languages, and in particular how sophisticated reactive objects cannot be defined in the language without using initialization holes, and how this forces ML programmers to break abstraction boundaries. At the same time we show how OO languages rely extensively on null pointers during initialization. We propose that a general, semi-safe mechanism allows value recursion to be used in conjunction with existing sophisicated abstract APIs such GUI libraries, and allows freshly defined APIs to be both abstract and yet not require clients to use explicit initialization holes. We propose that the initialization mechanism permits more programs to be expressed in the mutation-free fragment of ML, though we do not formally prove this result. 1

