Lambda the Ultimate - Type Theory
http://lambda-the-ultimate.org/taxonomy/term/21/0
enThe 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 +0000Breaking Through the Normalization Barrier: A Self-Interpreter for F-omega
http://lambda-the-ultimate.org/node/5276
<p ><a href="http://compilers.cs.ucla.edu/popl16/popl16-full.pdf">Breaking Through the Normalization Barrier: A Self-Interpreter for F-omega</a>, by Matt Brown and Jens Palsberg:</p>
<blockquote ><p >According to conventional wisdom, a self-interpreter for a strongly normalizing λ-calculus is impossible. We call this the normalization barrier. The normalization barrier stems from a theorem in computability theory that says that a total universal function for the total computable functions is impossible. In this paper we break through the normalization barrier and define a self-interpreter for System Fω, a strongly normalizing λ-calculus. After a careful analysis of the classical theorem, we show that static type checking in Fω can exclude the proof’s diagonalization gadget, leaving open the possibility for a self-interpreter. Along with the self-interpreter, we program four other operations in Fω, including a continuation-passing style transformation. Our operations rely on a new approach to program representation that may be useful in theorem provers and compilers.</p></blockquote>
<p >I haven't gone through the whole paper, but their claims are compelling. They have created self-interpreters in System F, System Fω and System Fω+, which are all strongly normalizing typed languages. Previously, the only instance of this for a typed language was <a href="http://lambda-the-ultimate.org/node/5176">Girard's System U</a>, which is not strongly normalizing. The key lynchpin appears in this paragraph on page 2:</p>
<blockquote ><p >Our result breaks through the normalization barrier. The conventional wisdom underlying the normalization barrier makes an implicit assumption that all representations will behave like their counterpart in the computability theorem, and therefore the theorem must apply to them as well. This assumption excludes other notions of representation, about which the theorem says nothing. Thus, our result does not contradict the theorem, but shows that the theorem is less far-reaching than previously thought.</p></blockquote>
<p >Pretty cool if this isn't too complicated in any given language. Could let one move some previously non-typesafe runtime features, into type safe libraries.</p>FunctionalTheoryType TheoryTue, 10 Nov 2015 14:23:32 +0000Dependent Types for Low-Level Programming
http://lambda-the-ultimate.org/node/5256
<p ><a href="http://www.cs.berkeley.edu/~necula/Papers/deputy-esop07.pdf">Dependent Types for Low-Level Programming</a> by Jeremy Condit, Matthew Harren, Zachary Anderson, David Gay, and George C. Necula:</p>
<blockquote ><p >In this paper, we describe the key principles of a dependent type system for low-level imperative languages. The major contributions of this work are (1) a sound type system that combines dependent types and mutation for variables and for heap-allocated structures in a more flexible way than before and (2) a technique for automatically inferring dependent types for local variables. We have applied these general principles to design Deputy, a dependent type system for C that allows the user to describe bounded pointers and tagged unions. Deputy has been used to annotate and check a number of real-world C programs.</p></blockquote>
<p >A conceptually simple approach to verifying the safety of C programs, which proceeeds in 3 phases: 1. infer locals that hold pointer bounds, 2. flow-insensitive checking introduces runtime assertions using these locals, 3. flow-sensitive optimization that removes the assertions that it can prove always hold.</p>
<p >You're left with a program that ensures runtime safety with as few runtime checks as possible, and the resulting C program is compiled with gcc which can perform its own optimizations.</p>
<p >This work is from 2007, and the project grew into the <a href="http://ivy.cs.berkeley.edu/ivywiki/index.php/Main/HomePage">Ivy language</a>, which is a C dialect that is fully backwards compatible with C if you #include a small header file that includes the extensions.</p>
<p >It's application to C probably won't get much uptake at this point, but I can see this as a useful compiler plugin to verify unsafe Rust code.</p>TheoryType TheoryMon, 28 Sep 2015 13:58:58 +0000Freer Monads, More Extensible Effects
http://lambda-the-ultimate.org/node/5244
<p ><a href="http://okmij.org/ftp/Haskell/extensible/more.pdf">Freer Monads, More Extensible Effects</a>, by Oleg Kiselyov and Hiromi Ishii:</p>
<blockquote ><p >We present a rational reconstruction of extensible effects, the recently proposed alternative to monad transformers, as the confluence of efforts to make effectful computations compose. Free monads and then extensible effects emerge from the straightforward term representation of an effectful computation, as more and more boilerplate is abstracted away. The generalization process further leads to freer monads, constructed without the Functor constraint.</p>
<p >The continuation exposed in freer monads can then be represented as an efficient type-aligned data structure. The end result is the algorithmically efficient extensible effects library, which is not only more comprehensible but also faster than earlier implementations. As an illustration of the new library, we show three surprisingly simple applications: non-determinism with committed choice (LogicT), catching IO exceptions in the presence of other effects, and the semi-automatic management of file handles and other resources through monadic regions.</p>
<p >We extensively use and promote the new sort of ‘laziness’, which underlies the left Kan extension: instead of performing an operation, keep its operands and pretend it is done.</p></blockquote>
<p >This looks very promising, and includes some benchmarks comparing the heavily optimized and special-cased monad transformers against this new formulation of extensible effects using Freer monads.</p>
<p >See also the <a href="https://www.reddit.com/r/haskell/comments/3joxd7/freer_monads_more_extensible_effects/">reddit discussion</a>.</p>FunctionalTheoryType TheorySat, 05 Sep 2015 14:30:02 +0000Self-Representation in Girard’s System U
http://lambda-the-ultimate.org/node/5176
<p ><a href="http://compilers.cs.ucla.edu/popl15/popl15-full.pdf">Self-Representation in Girard’s System U</a>, by Matt Brown and Jens Palsberg:</p>
<blockquote ><p >In 1991, Pfenning and Lee studied whether System F could support a typed self-interpreter. They concluded that typed self-representation for System F “seems to be impossible”, but were able to represent System F in Fω. Further, they found that the representation of Fω requires kind polymorphism, which is outside Fω. In 2009, Rendel, Ostermann and Hofer conjectured that the representation of kind-polymorphic terms would require another, higher form of polymorphism. Is this a case of infinite regress?</p>
<p >We show that it is not and present a typed self-representation for Girard’s System U, the first for a λ-calculus with decidable type checking. System U extends System Fω with kind polymorphic terms and types. We show that kind polymorphic types (i.e. types that depend on kinds) are sufficient to “tie the knot” – they enable representations of kind polymorphic terms without introducing another form of polymorphism. Our self-representation supports operations that iterate over a term, each of which can be applied to a representation of itself. We present three typed self-applicable operations: a self-interpreter that recovers a term from its representation, a predicate that tests the intensional structure of a term, and a typed continuation-passing-style (CPS) transformation – the first typed self-applicable CPS transformation. Our techniques could have applications from verifiably type-preserving metaprograms, to growable typed languages, to more efficient self-interpreters.</p></blockquote>
<p >Typed self-representation has <a href="http://lambda-the-ultimate.org/node/2438#comment-47966">come up</a> here on LtU <a href="http://lambda-the-ultimate.org/node/4785#comment-76876">in the past</a>. I believe the best self-interpreter available prior to this work was a variant of <a href="http://lambda-the-ultimate.org/node/3993">Barry Jay's SF-calculus</a>, covered in the paper <a href="http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.225.1765">Typed Self-Interpretation by Pattern Matching</a> (and more fully developed in <a href="http://www0.cs.ucl.ac.uk/staff/R.Rowe/docs/arb10.pdf">Structural Types for the Factorisation Calculus</a>). These covered statically typed self-interpreters without resorting to undecidable type:type rules.</p>
<p >However, being combinator calculi, they're not very similar to most of our programming languages, and so self-interpretation was still an active problem. Enter Girard's System U, which features a more familiar type system with only kind * and kind-polymorphic types. However, System U is not strongly normalizing and is inconsistent as a logic. Whether self-interpretation can be achieved in a strongly normalizing language with decidable type checking is still an open problem.</p>FunctionalLambda CalculusTheoryType TheoryThu, 11 Jun 2015 18:45:11 +0000Second-order logic explained in plain English
http://lambda-the-ultimate.org/node/5170
<p >John Corcoran, <a href="https://www.academia.edu/11975482/Second-order_logic_explained_in_plain_English_">Second-order logic explained in plain English</a>, in <i >Logic, Meaning and Computation: Essays in Memory of Alonzo Church</i>, ed. Anderson and Zelëny.</p>
<p >There is something a little bit Guy Steele-ish about trying to explain the fundamentals of second-order logic (SOL, the logic that Quine branded as set theory in sheep's clothing) and its model theory while avoiding any formalisation. This paper introduces the ideas of SOL via looking at logics with finite, countable and uncountable models, and then talks about FOL and SOL as being complementary approaches to axiomatisation that are each deficient by themself. He ends with a plea for SOL as being an essential tool at least as a heuristic.</p>Type TheoryThu, 28 May 2015 20:18:52 +0000