Lambda the Ultimate - Type Theory
http://lambda-the-ultimate.org/taxonomy/term/21/0
enThe Little Typer
http://lambda-the-ultimate.org/node/5552
<p >A new introductory book about dependent types, involving some familiar names:</p>
<p ><strong ><a href="https://mitpress.mit.edu/books/little-typer">The Little Typer</a></strong></p>
<p >by Daniel P. Friedman and David Thrane Christiansen.</p>
<p >Foreword by Robert Harper.</p>
<p >Afterword by Conor McBride.</p>
<blockquote ><p >
<strong >An introduction to dependent types, demonstrating the most beautiful aspects, one step at a time.</strong></p>
<p >A program's type describes its behavior. Dependent types are a first-class part of a language, and are much more powerful than other kinds of types; using just one language for types and programs allows program descriptions to be as powerful as the programs they describe. The Little Typer explains dependent types, beginning with a very small language that looks very much like Scheme and extending it to cover both programming with dependent types and using dependent types for mathematical reasoning. Readers should be familiar with the basics of a Lisp-like programming language, as presented in the first four chapters of The Little Schemer.</p>
<p >The first five chapters of The Little Typer provide the needed tools to understand dependent types; the remaining chapters use these tools to build a bridge between mathematics and programming. Readers will learn that tools they know from programming—pairs, lists, functions, and recursion—can also capture patterns of reasoning. The Little Typer does not attempt to teach either practical programming skills or a fully rigorous approach to types. Instead, it demonstrates the most beautiful aspects as simply as possible, one step at a time.
</p></blockquote>Type TheoryMon, 24 Sep 2018 04:29:49 +0000Safe Dynamic Memory Management in Ada and SPARK
http://lambda-the-ultimate.org/node/5541
<p ><a href="https://www.adacore.com/papers/safe-dynamic-memory-management-in-ada-and-spark">Safe Dynamic Memory Management in Ada and SPARK</a> by Maroua Maalej, Tucker Taft, Yannick Moy:</p>
<blockquote ><p >Handling memory in a correct and efficient way is a step toward safer, less complex, and higher performing software-intensive systems. However, languages used for critical software development such as Ada, which supports formal verification with its SPARK subset, face challenges regarding any use of pointers due to potential pointer aliasing. In this work, we introduce an extension to the Ada language, and to its SPARK subset, to provide pointer types (“access types” in Ada) that provide provably safe, automatic storage management without any asynchronous garbage collection, and without explicit deallocation by the user. Because the mechanism for these safe pointers relies on strict control of aliasing, it can be used in the SPARK subset for formal verification, including both information flow analysis and proof of safety and correctness properties. In this paper, we present this proposal (which has been submitted for inclusion in the next version of Ada), and explain how we are able to incorporate these pointers into formal analyses</p></blockquote>
<p >For the systems programmers among you, you might be interested in some new developments in Ada where they propose to add ownership types to Ada's pointer/access types, to improve the flexibility of the programs that can be written and whose safety can be automatically verified. The automated satisfiability of these safety properties is a key goal of the SPARK Ada subset.</p>ImplementationType TheoryThu, 26 Jul 2018 19:42:01 +0000The Gentle Art of Levitation
http://lambda-the-ultimate.org/node/5526
<a href="http://jmchapman.github.io/papers/levitation.pdf">The Gentle Art of Levitation</a>
<p >2010 by James Chapman, Pierre-Evariste Dagand, Conor McBride, Peter Morrisy</p>
<blockquote >
We present a closed dependent type theory whose inductive types
are given not by a scheme for generative declarations, but by encoding
in a universe. Each inductive datatype arises by interpreting its
description—a first-class value in a datatype of descriptions. Moreover,
the latter itself has a description. Datatype-generic programming
thus becomes ordinary programming. We show some of the
resulting generic operations and deploy them in particular, useful
ways on the datatype of datatype descriptions itself. Surprisingly
this apparently self-supporting setup is achievable without paradox
or infinite regress.
</blockquote>
It's datatype descriptions all the way down.SemanticsType TheoryFri, 11 May 2018 19:26:31 +0000Comprehending Ringads
http://lambda-the-ultimate.org/node/5525
<a href="http://www.cs.ox.ac.uk/jeremy.gibbons/publications/ringads.pdf">Comprehending Ringads</a>
<p >2016 by Jeremy Gibbons</p>
<blockquote >
Ringad comprehensions represent a convenient notation for expressing
database queries. The ringad structure alone does not provide
a good explanation or an efficient implementation of relational joins;
but by allowing heterogeneous comprehensions, involving both bag and
indexed table ringads, we show how to accommodate these too.
</blockquote>
Indexed/parametric/graded monads are the key (read the paper to understand the pun).Category TheorySemanticsType TheorySat, 05 May 2018 02:59:11 +0000Sequent Calculus as a Compiler Intermediate Language
http://lambda-the-ultimate.org/node/5519
<p ><a href="https://www.microsoft.com/en-us/research/wp-content/uploads/2016/04/sequent-calculus-icfp16.pdf">Sequent Calculus as a Compiler Intermediate Language</a><br >
2016 by Paul Downen, Luke Maurer, Zena M. Ariola, Simon Peyton Jones</p>
<blockquote ><p >
The typed λ-calculus arises canonically as the term language for a logic called natural deduction, using the Curry-Howard isomorphism: the pervasive connection between logic and programming languages asserting that propositions are types and proofs are programs. Indeed, for many people, the λ-calculus is the living embodiment of Curry-Howard.</p>
<p >But natural deduction is not the only logic! Conspicuously, natural deduction has a twin, born in the very same paper, called the sequent calculus. Thanks to the Curry-Howard isomorphism, terms of the sequent calculus can also be seen as a programming language with an emphasis on control flow.
</p></blockquote>FunctionalGeneralLambda CalculusSemanticsType TheoryMon, 02 Apr 2018 17:06:41 +0000The Syntax and Semantics of Quantitative Type Theory
http://lambda-the-ultimate.org/node/5453
<p ><a href="http://bentnib.org/quantitative-type-theory.html">The Syntax and Semantics of Quantitative Type Theory</a> by Robert Atkey:</p>
<blockquote ><p >Type Theory offers a tantalising promise: that we can program and reason within a single unified system. However, this promise slips away when we try to produce efficient programs. Type Theory offers little control over the intensional aspect of programs: how are computational resources used, and when can they be reused. Tracking resource usage via types has a long history, starting with Girard's Linear Logic and culminating with recent work in contextual effects, coeffects, and quantitative type theories. However, there is conflict with full dependent Type Theory when accounting for the difference between usages in types and terms. Recently, McBride has proposed a system that resolves this conflict by treating usage in types as a zero usage, so that it doesn't affect the usage in terms. This leads to a simple expressive system, which we have named Quantitative Type Theory (QTT).</p>
<p >McBride presented a syntax and typing rules for the system, as well as an erasure property that exploits the difference between “not used” and “used”, but does not do anything with the finer usage information. In this paper, we present present a semantic interpretation of a variant of McBride's system, where we fully exploit the usage information. We interpret terms simultaneously as having extensional (compile-time) content and intensional (runtime) content. In our example models, extensional content is set-theoretic functions, representing the compile-time or type-level content of a type-theoretic construction. Intensional content is given by realisers for the extensional content. We use Abramsky et al.'s Linear Combinatory Algebras as realisers, yield a large range of potential models from Geometry of Interaction, graph models, and syntactic models. Read constructively, our models provide a resource sensitive compilation method for QTT.</p>
<p >To rigorously define the structure required for models of QTT, we introduce the concept of a Quantitative Category with Families, a generalisation of the standard Category with Families class of models of Type Theory, and show that this class of models soundly interprets Quantitative Type Theory.</p></blockquote>
<p >Resource-aware programming is a hot topic these days, with Rust exploiting affine and ownership types to scope and track resource usage, and with <a href="http://lambda-the-ultimate.org/node/5003">Ethereum</a> requiring programs to spend "gas" to execute. Combining linear and dependent types has proven difficult though, so making it easier to track and reason about resource usage in dependent type theories would then be a huge benefit to making verification more practical in domains where resources are limited.</p>SemanticsTheoryType TheoryTue, 25 Jul 2017 17:28:17 +0000RustBelt: Securing the Foundations of the Rust Programming Language
http://lambda-the-ultimate.org/node/5448
<p ><a href="https://www.ralfj.de/blog/2017/07/08/rustbelt.html">RustBelt: Securing the Foundations of the Rust Programming Language</a> by Ralf Jung, Jacques-Henri Jourdan, Robbert Krebbers, Derek Dreyer:</p>
<blockquote ><p >
Rust is a new systems programming language that promises to overcome the seemingly fundamental tradeoff between high-level safety guarantees and low-level control over resource management. Unfortunately, none of Rust’s safety claims have been formally proven, and there is good reason to question whether they actually hold. Specifically, Rust employs a strong, ownership-based type system, but then extends the expressive power of this core type system through libraries that internally use unsafe features. In this paper, we give the first formal (and machine-checked) safety proof for a language representing a realistic subset of Rust. Our proof is extensible in the sense that, for each new Rust library that uses unsafe features, we can say what verification condition it must satisfy in order for it to be deemed a safe extension to the language. We have carried out this verification for some of the most important libraries that are used throughout the Rust ecosystem.
</p></blockquote>
<p >Rust is definitely pushing the envelope in a new direction, but there's always a little wariness around using libraries that make use of unsafe features, since "safety with performance" is a main reason people want to use Rust. So this is a great step in the right direction!</p>FunctionalObject-FunctionalType TheoryMon, 10 Jul 2017 15:14:45 +0000Type Systems as Macros
http://lambda-the-ultimate.org/node/5426
<p ><a href="http://www.ccs.neu.edu/home/stchang/pubs/ckg-popl2017.pdf">Type Systems as Macros</a>, by Stephen Chang, Alex Knauth, Ben Greenman:</p>
<blockquote ><p >We present TURNSTILE, a metalanguage for creating typed embedded languages. To implement the type system, programmers write type checking rules resembling traditional judgment syntax. To implement the semantics, they incorporate elaborations into these rules. TURNSTILE critically depends on the idea of linguistic reuse. It exploits a <em >macro system</em> in a novel way to simultaneously type check and rewrite a surface program into a target language. Reusing a macro system also yields modular implementations whose rules may be mixed and matched to create other languages. Combined with typical compiler and runtime reuse, TURNSTILE produces performant typed embedded languages with little effort.</p></blockquote>
<p >This looks pretty awesome considering it's not limited to simple typed languages, but extends all the way to System F and F-omega! Even better, they can reuse previous type systems to define new ones, thereby reducing the effort to implement more expressive type systems. All code and further details <a href="http://www.ccs.neu.edu/home/stchang/popl2017/">available here</a>, and <a href="http://blog.racket-lang.org/2017/04/type-tailoring.html">here's a blog post</a> where Ben Greenman further discusses the related "type tailoring", and of course, these are both directly related to <a href="http://lambda-the-ultimate.org/node/1339">Active Libraries</a>.</p>
<p >Taken to its extreme, why not have an assembler with a powerful macro system of this sort as your host language, and every high-level language would be built on this. I'm not sure if this approach would extend that far, but it's an interesting idea. You'd need a cpp-like highly portable macro tool, and porting to a new platform consists of writing architecture-specific macros for some core language, like System F.</p>
<p >This work may also conceptually dovetail with <a href="http://lambda-the-ultimate.org/node/5424">another thread discussing fexprs and compilation</a>.</p>DSLFunctionalLambda CalculusMeta-ProgrammingType TheoryWed, 19 Apr 2017 23:38:56 +0000Contextual isomorphisms
http://lambda-the-ultimate.org/node/5398
<p >
<a href="http://www.cs.bham.ac.uk/~pbl/papers/contextiso.pdf">Contextual Isomorphisms</a><br >
Paul Blain Levy<br >
2017<br >
</p>
<blockquote >
<p >
What is the right notion of "isomorphism" between types, in a simple
type theory? The traditional answer is: a pair of terms that are
inverse, up to a specified congruence. We firstly argue that, in the
presence of effects, this answer is too liberal and needs to be
restricted, using Führmann’s notion of thunkability in the case of
value types (as in call-by-value), or using Munch-Maccagnoni’s notion
of linearity in the case of computation types (as in
call-by-name). Yet that leaves us with different notions of
isomorphism for different kinds of type.
</p>
<p >
This situation is resolved by means of a new notion of “contextual”
isomorphism (or morphism), analogous at the level of types to
contextual equivalence of terms. A contextual morphism is a way of
replacing one type with the other wherever it may occur in
a judgement, in a way that is preserved by the action of any term with
holes. For types of pure λ-calculus, we show that a contextual
morphism corresponds to a traditional isomorphism. For value types,
a contextual morphism corresponds to a thunkable isomorphism, and for
computation types, to a linear isomorphism.
</p>
</blockquote>
<p >This paper is based on a very simple idea that everyone familiar
with type-systems can enjoy. It then applies it in a technical setting
in which it brings a useful contribution. I suspect that many readers
will find that second part too technical, but they may still enjoy the
idea itself. To facilitate this, I will rephrase the abstract above in
a way that I hope makes it accessible to a larger audience.</p>
<p >The problem that the paper solves is: how do we know what it means
for two types to be equivalent? For many languages they are reasonable
definitions of equivalence (such that: there exists a bijection
between these two types in the language), but for more advanced
languages these definitions break down. For example, in presence of
hidden mutable state, one can build a pair of functions from the
one-element type <code >unit</code> to the two-element
type <code >bool</code> and back that are the identity when composed
together -- the usual definition of bijection -- while these two types
should probably not be considered "the same". Those two functions
share some hidden state, so they "cheat". Other, more complex notions
of type equivalence have been given in the literature, but how do we
know whether they are the "right" notions, or whether they may
disappoint us in the same way?</p>
<p >To define what it means for two program fragments to be equivalent,
we have a "gold standard", which is contextual equivalence: two
program fragments are contextually equivalent if we can replace one
for the other in any complete program without changing its
behavior. This is simple to state, it is usually clear how to
instantiate this definition for a new system, and it gives you
a satisfying notion of equivalent. It may not be the most convenient
one to work with, so people define others, more specific notions of
equivalence (typically beta-eta-equivalence or logical relations); it
is fine if they are more sophisticated, and their definiton harder to
justify or understand, because they can always be compared to this
simple definition to gain confidence.</p>
<p >The simple idea in the paper above is to use this exact same trick
to define what it means for two <em >types</em> to be
equivalent. Naively, one could say that two types are equivalent if,
in any well-typed program, one can replace some occurrences of the
first type by occurrences of the second type, all other things being
unchanged. This does not quite work, as changing the types that appear
in a program without changing its terms would create ill-typed
terms. So instead, the paper proposes that two types are equivalent
when we are told how to transform any program using the first type
into a program using the second type, in a way that is bijective
(invertible) and compositional -- see the paper for details.</p>
<p >Then, the author can validate this definition by showing that, when
instantiated to languages (simple or complex) where existing notions
of equivalence have been proposed, this new notion of equivalence
corresponds to the previous notions.</p>
<p >(Readers may find that even the warmup part of the paper, namely
the sections 1 to 4, pages 1 to 6, are rather dense, with a compactly
exposed general idea and arguably a lack of concrete examples that would help
understanding. Surely this terseness is in large part a consequence of
strict page limits -- conference articles are the tweets of computer
science research. A nice side-effect (no pun intended) is that you can
observe a carefully chosen formal language at work, designed to expose
the setting and perform relevant proofs in minimal space: category
theory, and in particular the concept of naturality, is the killer
space-saving measure here.)</p>Type TheoryFri, 09 Dec 2016 21:37:50 +0000Polymorphism, subtyping and type inference in MLsub
http://lambda-the-ultimate.org/node/5393
<p >I am very enthusiastic about the following paper: it brings new ideas and solves a problem that I did not expect to be solvable, namely usable type inference when both polymorphism and subtyping are implicit. (By "usable" here I mean that the inferred types are both compact and principal, while previous work generally had only one of those properties.)</p>
<p >
<a href="http://www.cl.cam.ac.uk/%7Esd601/papers/mlsub-preprint.pdf">Polymorphism, Subtyping, and Type Inference in MLsub</a><br >
Stephen Dolan and Alan Mycroft<br >
2017</p>
<blockquote >
<p >We present a type system combining subtyping and ML-style parametric polymorphism. Unlike previous work, our system supports
type inference and has compact principal types. We demonstrate
this system in the minimal language MLsub, which types a strict
superset of core ML programs.</p>
<p >This is made possible by keeping a strict separation between
the types used to describe inputs and those used to describe outputs, and extending the classical unification algorithm to handle
subtyping constraints between these input and output types. Principal types are kept compact by type simplification, which exploits
deep connections between subtyping and the algebra of regular languages. An implementation is available online.</p>
</blockquote>
<p >The paper is full of interesting ideas. For example, one idea is that adding type variables to the base grammar of types -- instead of defining them by their substitution -- forces us to look at our type systems in ways that are more open to extension with new features. I would recommend looking at this paper even if you are interested in ML and type inference, but not subtyping, or in polymorphism and subtyping, but not type inference, or in subtyping and type inference, but not functional languages.</p>
<p >This paper is also a teaser for the first's author PhD thesis, <a href="https://www.cl.cam.ac.uk/~sd601/thesis.pdf"><em >Algebraic Subtyping</em></a>. There is also an <a href="https://www.cl.cam.ac.uk/~sd601/mlsub/">implementation</a> available.</p>
<p >(If you are looking for interesting work on inference of polymorphism and subtyping in object-oriented languages, I would recommend <a href="http://www.cs.cornell.edu/~ross/publications/shapes/">Getting F-Bounded Polymorphism into Shape</a> by Ben Greenman, Fabian Muehlboeck and Ross Tate, 2014.)</p>Type TheoryWed, 23 Nov 2016 16:54:15 +0000Proving Programs Correct Using Plain Old Java Types
http://lambda-the-ultimate.org/node/5387
<p ><a href="http://fpl.cs.depaul.edu/jriely/papers/2009-pojt.pdf">Proving Programs Correct Using Plain Old Java Types</a>, by Radha Jagadeesan, Alan Jeffrey, Corin Pitcher, James Riely:</p>
<blockquote ><p >Tools for constructing proofs of correctness of programs have a long history of development in the research community, but have often faced difficulty in being widely deployed in software development tools. In this paper, we demonstrate that the off-the-shelf Java type system is already powerful enough to encode non-trivial proofs of correctness using propositional Hoare preconditions and postconditions.</p>
<p >We illustrate the power of this method by adapting Fähndrich and Leino’s work on monotone typestates and Myers and Qi’s closely related work on object initialization. Our approach is expressive enough to address phased initialization protocols and the creation of cyclic data structures, thus allowing for the elimination of null and the special status of constructors. To our knowledge, our system is the first that is able to statically validate standard one-pass traversal algorithms for cyclic graphs, such as those that underlie object deserialization. Our proof of correctness is mechanized using the Java type system, without any extensions to the Java language.</p></blockquote>
<p >Not a new paper, but it provides a lightweight verification technique for some program properties that you can use right now, without waiting for integrated theorem provers or SMT solvers. Properties that require only monotone typestates can be verified, ie. those that operations can only move the typestate "forwards".</p>
<p >In order to achieve this, they require programmers to follow a few simple rules to avoid Java's pervasive nulls. These are roughly: don't assign null explicitly, be sure to initialize all fields when constructing objects.</p>OOPType TheoryFri, 04 Nov 2016 14:27:32 +0000Fully Abstract Compilation via Universal Embedding
http://lambda-the-ultimate.org/node/5364
<p ><a href="https://www.williamjbowman.com/resources/fabcc-paper.pdf">Fully Abstract Compilation via Universal Embedding</a> by Max S. New, William J. Bowman, and Amal Ahmed:</p>
<blockquote ><p >A <em >fully abstract</em> compiler guarantees that two source components are observationally equivalent in the source language if and only if their translations are observationally equivalent in the target. Full abstraction implies the translation is secure: target-language attackers can make no more observations of a compiled component than a source-language attacker interacting with the original source component. Proving full abstraction for realistic compilers is challenging because realistic target languages contain features (such as control effects) unavailable in the source, while proofs of full abstraction require showing that every target context to which a compiled component may be linked can be back-translated to a behaviorally equivalent source context.</p>
<p >We prove the first full abstraction result for a translation whose target language contains exceptions, but the source does not. Our translation—specifically, closure conversion of simply typed λ-calculus with recursive types—uses types at the target level to ensure that a compiled component is never linked with attackers that have more distinguishing power than source-level attackers. We present a new back-translation technique based on a deep embedding of the target language into the source language at a dynamic type. Then boundaries are inserted that mediate terms between the untyped embedding and the strongly-typed source. This technique allows back-translating non-terminating programs, target features that are untypeable in the source, and well-bracketed effects.</p></blockquote>
<p >Potentially a promising step forward to secure multilanguage runtimes. We've previously discussed security vulnerabilities caused by full abstraction failures <a href="http://lambda-the-ultimate.org/node/3830">here</a> and <a href="http://lambda-the-ultimate.org/node/1588">here</a>. The paper also provides a comprehensive review of associated literature, like various means of protection, back translations, embeddings, etc.</p>Lambda CalculusSemanticsTheoryType TheoryWed, 27 Jul 2016 15:57:02 +0000Set-Theoretic Types for Polymorphic Variants
http://lambda-the-ultimate.org/node/5351
<p ><a href="http://arxiv.org/pdf/1606.01106v1.pdf">Set-Theoretic Types for Polymorphic Variants</a> by Giuseppe Castagna, Tommaso Petrucciani, and Kim Nguyễn:</p>
<blockquote ><p >Polymorphic variants are a useful feature of the OCaml language whose current definition and implementation rely on kinding constraints to simulate a subtyping relation via unification. This yields an awkward formalization and results in a type system whose behaviour is in some cases unintuitive and/or unduly restrictive.</p>
<p >In this work, we present an alternative formalization of polymorphic variants, based on set-theoretic types and subtyping, that yields a cleaner and more streamlined system. Our formalization is more expressive than the current one (it types more programs while preserving type safety), it can internalize some meta-theoretic properties, and it removes some pathological cases of the current implementation resulting in a more intuitive and, thus, predictable type system. More generally, this work shows how to add full-fledged union types to functional languages of the ML family that usually rely on the Hindley-Milner type system. As an aside, our system also improves the theory of semantic subtyping, notably by proving completeness for the type reconstruction algorithm.</p></blockquote>
<p >Looks like a nice result. They integrate union types and restricted intersection types for complete type inference, which prior work on CDuce could not do. The disadvantage is that it does not admit principal types, and so inference is non-deterministic (see section 5.3.2).</p>FunctionalType TheoryThu, 09 Jun 2016 13:38:24 +0000No value restriction is needed for algebraic effects and handlers
http://lambda-the-ultimate.org/node/5343
<p ><a href="https://arxiv.org/pdf/1605.06938v1.pdf">No value restriction is needed for algebraic effects and handlers</a>, by Ohad Kammar and Matija Pretnar:</p>
<blockquote ><p >We present a straightforward, sound Hindley-Milner polymorphic type system for algebraic effects and handlers in a call-by-value calculus, which allows type variable generalisation of arbitrary computations, not just values. This result is surprising. On the one hand, the soundness of unrestricted call-by-value Hindley-Milner polymorphism is known to fail in the presence of computational effects such as reference cells and continuations. On the other hand, many programming examples can be recast to use effect handlers instead of these effects. Analysing the expressive power of effect handlers with respect to state effects, we claim handlers cannot express reference cells, and show they can simulate dynamically scoped state.</p></blockquote>
<p >Looks like a nice integration of algebraic effects with simple Hindly-Milner, but which yields some unintuitive conclusions. At least I certainly found the possibility of supporting dynamically scoped state but not reference cells surprising!</p>
<p >It highlights the need for some future work to support true reference cells, namely a polymorphic type and effect system to generate fresh instances.</p>EffectsFunctionalType TheoryWed, 25 May 2016 13:54:59 +0000Type Checking Modular Multiple Dispatch with Parametric Polymorphism and Multiple Inheritance
http://lambda-the-ultimate.org/node/5322
<p ><a href="http://www.mpi-sws.org/~skilpat/papers/multipoly.pdf">Type Checking Modular Multiple Dispatch with Parametric Polymorphism and Multiple Inheritance</a> by Eric Allen, Justin Hilburn, Scott Kilpatrick, Victor Luchangco, Sukyoung Ryu, David Chase, Guy L. Steele Jr.:</p>
<blockquote ><p >
In previous work, we presented rules for defining overloaded functions that ensure type safety under symmetric multiple dispatch in an object-oriented language with multiple inheritance, and we showed how to check these rules without requiring the entire type hierarchy to be known, thus supporting modularity and extensibility. In this work, we extend these rules to a language that supports parametric polymorphism on both classes and functions.</p>
<p >In a multiple-inheritance language in which any type may be extended by types in other modules, some overloaded functions that might seem valid are correctly rejected by our rules. We explain how these functions can be permitted in a language that additionally supports an exclusion relation among types, allowing programmers to declare “nominal exclusions” and also implicitly imposing exclusion among different instances of each polymorphic type. We give rules for computing the exclusion relation, deriving many type exclusions from declared and implicit ones.</p>
<p >We also show how to check our rules for ensuring the safety of overloaded functions. In particular, we reduce the problem of handling parametric polymorphism to one of determining subtyping relationships among universal and existential types. Our system has been implemented as part of the open-source Fortress compiler.
</p></blockquote>
<p ><a href="http://lambda-the-ultimate.org/node/4570">Fortress</a> was briefly covered here a couple of times, as were multimethods and <a href="http://lambda-the-ultimate.org/node/3061">multiple dispatch</a>, but this paper really generalizes and nicely summarizes <a href="http://web.cs.ucla.edu/~todd/research/iandc.pdf">previous work</a> on statically typed modular multimethods, and does a good job explaining the typing rules in an accessible way. The integration with parametric polymorphism I think is key to applying multimethods in other domains which may want modular multimethods, but not multiple inheritance.</p>
<p >The <a href="http://www.cs.yale.edu/homes/jieung/Publication/cpp_paper.pdf">Formalization in COQ</a> might also be of interest to some.</p>
<p >Also, another interesting point is Fortress' use of second-class intersection and union types to simplify type checking.</p>Object-FunctionalTheoryType TheoryFri, 01 Apr 2016 01:25:22 +0000