Private Row Types: Abstracting the Unnamed

Garrigue, Jacques

doi:10.1007/11924661_3

Cited by 6 publications

(4 citation statements)

References 16 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…These are known as partially abstract types [6], and are available as a language feature in OCaml [13] and Moby [11]. However, implementing these via first-class subtypes allows more flexibility: for example, they allow some of the methods of an object type to be hidden from the exposed interface, and also support the dual of private types (called invisible types [16]), and zero cost-coercions [5], where coercions in both directions are available, but actual type equality is not exposed.…”

Section: Selective Abstractionmentioning

confidence: 99%

First-Class Subtypes

Yallop

Dolan

2019

Electron. Proc. Theor. Comput. Sci.

View full text Add to dashboard Cite

First class type equalities, in the form of generalized algebraic data types (GADTs), are commonly found in functional programs. However, first-class representations of other relations between types, such as subtyping, are not yet directly supported in most functional programming languages.We present several encodings of first-class subtypes using existing features of the OCaml language (made more convenient by the proposed modular implicits extension), show that any such encodings are interconvertible, and illustrate the utility of the encodings with several examples. # let o = object method m = () end;; val o : < m : unit > = # (lazy o :> < > Lazy.t);; -: < > Lazy.t = An attempt to similarly coerce our Lzy.t fails: # (Lzy.delay (fun () → o) :> < > Lzy.t);; Characters 0-40: (Lzy.delay (fun () → o) :> < > Lzy.t);;^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^Ê rror: Type < m : unit > Lzy.t is not a subtype of < > Lzy.t The second object type has no method mSecond, let-bound computations constructed using the built-in lazy receive polymorphic types, following the relaxed value restriction, which generalizes type variables that appear only in covariant positions [12]:

show abstract

Section: Selective Abstractionmentioning

confidence: 99%

First-Class Subtypes

Yallop

Dolan

2019

Electron. Proc. Theor. Comput. Sci.

View full text Add to dashboard Cite

show abstract

“…OCaml's structurally typed polymorphic variants are distinguished by a leading backtick ' for each constructor: for instance, 'Unknown_file s has the type The revised Store signature exposes a type error, consisting of general errors expected to be encountered by any Store implementation, along with a pretty printer [Bonichon and Weis 2017] that builds a humanreadable representation of an error (Line 3). By making the error type private [Garrigue 2006], we allow the implementation to provide a richer error type, as long as it contains at least the specified elements. Module type signatures with functions that may return an error use the result type to return either the result of a successful call or the relevant error information.…”

Section: Reporting Errorsmentioning

confidence: 99%

Programming Unikernels in the Large via Functor Driven Development

Radanne¹,

Gazagnaire²,

Madhavapeddy³

et al. 2019

Preprint

View full text Add to dashboard Cite

Compiling applications as unikernels allows them to be tailored to diverse execution environments. Dependency on a monolithic operating system is replaced with linkage against libraries that provide specific services. Doing so in practice has revealed a major barrier: managing the configuration matrix across heterogenous execution targets. A realistic unikernel application depends on hundreds of libraries, each of which may place different demands on the different target execution platforms (e.g., cryptographic acceleration).We propose a modular approach to structuring large scale codebases that cleanly separates configuration, application and operating system logic. Our implementation is built on the MirageOS unikernel framework, using the OCaml language's powerful abstraction and metaprogramming facilities. Leveraging modules allows us to build many components independently, with only loose coupling through a set of standardised signatures. Components can be parameterized by other components and composed. Our approach accounts for state, dependency ordering, and error management, and our usage over the years has demonstrated significant efficiency benefits by leveraging compiler features such as global link-time optimisation during the configuration process. We describe our application architecture and experiences via some practical applications of our approach, and discuss how library development in MirageOS can facilitate adoption in other unikernel frameworks and programming languages.

show abstract

“…Despite such abundant literature and practical implementations, however, the number of examples of using recursive modules reported in the literature is still rather limited: expression/binding recursive modules [6], Okasaki's bootstrapped heaps [31], polymorphic recursion [21], tree/forest recursive data structures [28], and the expression problem [13]. While they give us some idea of how recursive modules can be useful in practice, their scarcity may also demonstrate that existing systems are either too cumbersome or not expressive enough to accommodate other interesting examples.…”

Section: Introductionmentioning

confidence: 99%

A syntactic type system for recursive modules

Nakata

Garrigue

et al. 2011

Proceedings of the 2011 ACM International Conference on Object Oriented Programming Systems Languages and Applications

Self Cite

View full text Add to dashboard Cite

A practical type system for ML-style recursive modules should address at least two technical challenges. First, it needs to solve the double vision problem, which refers to an inconsistency between external and internal views of recursive modules. Second, it needs to overcome the tension between practical decidability and expressivity which arises from the potential presence of cyclic type definitions caused by recursion between modules. Although type systems in previous proposals solve the double vision problem and are also decidable, they fail to typecheck common patterns of recursive modules, such as functor fixpoints, that are essential to the expressivity of the module system and the modular development of recursive modules. This paper proposes a novel type system for recursive modules that solves the double vision problem and typechecks common patterns of recursive modules including functor fixpoints. First, we design a type system with a type equivalence based on weak bisimilarity, which does not lend itself to practical implementation in general, but accommodates a broad range of cyclic type definitions. Then, we identify a practically implementable fragment using a type equivalence based on type normalization, which is expressive enough to typecheck typical uses of recursive modules. Our approach is purely syntactic and the definition of the type system is ready for use in an actual implementation.

show abstract

Private Row Types: Abstracting the Unnamed

Cited by 6 publications

References 16 publications

First-Class Subtypes

First-Class Subtypes

Programming Unikernels in the Large via Functor Driven Development

A syntactic type system for recursive modules

Contact Info

Product

Resources

About