A type system for higher-order modules

DreyerDerek,; CraryKarl,; HarperRobert,

doi:10.1145/640128.604151

Cited by 29 publications

(75 citation statements)

References 25 publications

(41 reference statements)

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Several proposals have been made (Shao, 1999;Dreyer et al, 2003;Russo, 2003), but all of them suffer from breaking abstraction safety (cf. Section 8 for examples).…”

Section: Related Work and Discussionmentioning

confidence: 99%

“…The module calculus of Dreyer et al (2003) provides support for both the "strong" Shao-style sealing construct, which demands generativity of (immediately) enclosing functors, and a "weak" variant of sealing, which does not demand generativity and may thus be used inside applicative functors. Dreyer et al account for these two variants in terms of a dichotomy between "dynamic effects" and "static effects".…”

Section: Related Work and Discussionmentioning

confidence: 99%

“…The failure to provide abstraction safety is not a peculiar fault of our semantics: contrary to popular belief, none of the existing accounts of applicative functors in the literature (or in ML compilers) provide abstraction safety either Leroy, 1995;Russo, 1998;Shao, 1999;Dreyer et al, 2003). The reason, in short, is that tracking only static purity of module expressions -as we have done in the previous section, and as other approaches have done before us -is not sufficient: it is important for the purpose of abstraction safety to track dynamic purity as well.…”

mentioning

confidence: 86%

“…As mentioned above, the central insight of viewing the seemingly dependent type system of ML modules through the lens of System F types is due to Russo (1998;, and many of the ideas for translating module terms are already present in prior work by Harper et al (1990), Harper & Stone (2000), and Dreyer (2007b). Our technical development of applicative functors is directly influenced by the work of Biswas (1995), Russo (1998;2003), and Shan (2004), and more indirectly by Shao (1999) and Dreyer et al (2003). But instead of frontloading this article with a survey of the literature, we will point to the origins of some key ideas as we come to them.…”

Section: Introductionmentioning

confidence: 94%

See 3 more Smart Citations

F-ing modules

Rossberg¹,

Russo²,

Dreyer

2014

J. Funct. Prog.

Self Cite

View full text Add to dashboard Cite

ML modules are a powerful language mechanism for decomposing programs into reusable components. Unfortunately, they also have a reputation for being "complex" and requiring fancy type theory that is mostly opaque to non-experts. While this reputation is certainly understandable, given the many non-standard methodologies that have been developed in the process of studying modules, we aim here to demonstrate that it is undeserved. To do so, we present a novel formalization of ML modules, which defines their semantics directly by a compositional "elaboration" translation into plain System F ω (the higher-order polymorphic λ-calculus). To demonstrate the scalability of our "F-ing" semantics, we use it to define a representative, higher-order ML-style module language, encompassing all the major features of existing ML module dialects (except for recursive modules). We thereby show that ML modules are merely a particular mode of use of System F ω .To streamline the exposition, we present the semantics of our module language in stages. We begin by defining a subset of the language supporting a Standard ML-like language with second-class modules and generative functors. We then extend this sublanguage with the ability to package modules as first-class values (a very simple extension, as it turns out) and OCaml-style applicative functors (somewhat harder). Unlike previous work combining both generative and applicative functors, we do not require two distinct forms of functor or signature sealing. Instead, whether a functor is applicative or not depends only on the computational purity of its body. In fact, we argue that applicative/generative is rather incidental terminology for pure versus impure functors. This approach results in a semantics that we feel is simpler and more natural than previous accounts, and moreover prohibits breaches of abstraction safety that were possible under them.

show abstract

“…Several proposals have been made (Shao, 1999;Dreyer et al, 2003;Russo, 2003), but all of them suffer from breaking abstraction safety (cf. Section 8 for examples).…”

Section: Related Work and Discussionmentioning

confidence: 99%

Section: Related Work and Discussionmentioning

confidence: 99%

mentioning

confidence: 86%

Section: Introductionmentioning

confidence: 94%

See 2 more Smart Citations

F-ing modules

Rossberg¹,

Russo²,

Dreyer

2014

J. Funct. Prog.

Self Cite

View full text Add to dashboard Cite

show abstract

“…Shan [30] presents a formal translation from a sophisticated ML module calculus [31] into System F ω [32]. The source ML module calculus is a unified formalism that covers a large part of the design space of ML modules.…”

Section: Related Workmentioning

confidence: 99%

ML Modules and Haskell Type Classes: A Constructive Comparison

Wehr

Chakravarty

2008

Lecture Notes in Computer Science

View full text Add to dashboard Cite

show abstract

Parameterized Modules for Classes and Extensible Functions

Lee

Chambers

2006

ECOOP 2006 – Object-Oriented Programming

View full text Add to dashboard Cite

Abstract. We present F(Eml), a language that combines classes, extensible functions, symmetric multiple dispatching, and a practical system for parameterized modules. Parameterized modules permit subclasses and function extensions to be defined and typechecked once, and then reused to extend multiple argument modules. F(Eml)'s predecessor, Eml, supported classes and extensible functions with multiple dispatch, but its support for parameterized modules was weak. F(Eml)'s key novel features are alias declarations, generalized type relations in module signatures, and a nontrivial definition of signature subsumption.

show abstract

A type system for higher-order modules

Cited by 29 publications

References 25 publications

F-ing modules

F-ing modules

ML Modules and Haskell Type Classes: A Constructive Comparison

Parameterized Modules for Classes and Extensible Functions

Contact Info

Product

Resources

About