Injective Type Families for Haskell

Haskell, as implemented by the Glasgow Haskell Compiler (GHC), allows expressive type-level programming. The most popular type- level programming extension is TypeFamilies, which allows users to write functions on types. Yet, using type functions can cripple type inference in certain situations. In particular, lack of injectivity in type functions means that GHC can never infer an instantiation of a type variable appearing only under type functions. In this paper, we describe a small modification to GHC that allows type functions to be annotated as injective. GHC naturally must check validity of the injectivity annotations. The algorithm to do so is surprisingly subtle. We prove soundness for a simplification of our algorithm, and state and prove a completeness property, though the algorithm is not fully complete. As much of our reasoning surrounds functions defined by a simple pattern-matching structure, we believe our results extend beyond just Haskell. We have implemented our solution on a branch of GHC and plan to make it available to regular users with the next stable release of the compiler

Injective Type Families for Haskell

Haskell, as implemented by the Glasgow Haskell Compiler (GHC), allows expressive type-level programming. The most popular type- level programming extension is TypeFamilies, which allows users to write functions on types. Yet, using type functions can cripple type inference in certain situations. In particular, lack of injectivity in type functions means that GHC can never infer an instantiation of a type variable appearing only under type functions. In this paper, we describe a small modification to GHC that allows type functions to be annotated as injective. GHC naturally must check validity of the injectivity annotations. The algorithm to do so is surprisingly subtle. We prove soundness for a simplification of our algorithm, and state and prove a completeness property, though the algorithm is not fully complete. As much of our reasoning surrounds functions defined by a simple pattern-matching structure, we believe our results extend beyond just Haskell. We have implemented our solution on a branch of GHC and plan to make it available to regular users with the next stable release of the compiler

Injective Type Families for Haskell

Haskell, as implemented by the Glasgow Haskell Compiler (GHC), allows expressive type-level programming. The most popular type- level programming extension is TypeFamilies, which allows users to write functions on types. Yet, using type functions can cripple type inference in certain situations. In particular, lack of injectivity in type functions means that GHC can never infer an instantiation of a type variable appearing only under type functions. In this paper, we describe a small modification to GHC that allows type functions to be annotated as injective. GHC naturally must check validity of the injectivity annotations. The algorithm to do so is surprisingly subtle. We prove soundness for a simplification of our algorithm, and state and prove a completeness property, though the algorithm is not fully complete. As much of our reasoning surrounds functions defined by a simple pattern-matching structure, we believe our results extend beyond just Haskell. We have implemented our solution on a branch of GHC and plan to make it available to regular users with the next stable release of the compiler

Injective Type Families for Haskell (extended version)

Haskell, as implemented by the Glasgow Haskell Compiler (GHC), allows expressive type-level programming. The most popular type- level programming extension is TypeFamilies, which allows users to write functions on types. Yet, using type functions can cripple type inference in certain situations. In particular, lack of injectivity in type functions means that GHC can never infer an instantiation of a type variable appearing only under type functions. In this paper, we describe a small modification to GHC that allows type functions to be annotated as injective. GHC naturally must check validity of the injectivity annotations. The algorithm to do so is surprisingly subtle. We prove soundness for a simplification of our algorithm, and state and prove a completeness property, though the algorithm is not fully complete. As much of our reasoning surrounds functions defined by a sim- ple pattern-matching structure, we believe our results extend be- yond just Haskell. We have implemented our solution on a branch of GHC and plan to make it available to regular users with the next stable release of the compiler

On certain extension properties for the space of compact operators

Let $Z$ be a fixed separable operator space, $X\subset Y$ general separable operator spaces, and $T:X\to Z$ a completely bounded map. $Z$ is said to have the Complete Separable Extension Property (CSEP) if every such map admits a completely bounded extension to $Y$; the Mixed Separable Extension Property (MSEP) if every such $T$ admits a bounded extension to $Y$. Finally, $Z$ is said to have the Complete Separable Complementation Property (CSCP) if $Z$ is locally reflexive and $T$ admits a completely bounded extension to $Y$ provided $Y$ is locally reflexive and $T$ is a complete surjective isomorphism. Let ${\bf K}$ denote the space of compact operators on separable Hilbert space and ${\bf K}_0$ the $c_0$ sum of {\Cal M}_n's (the space of ``small compact operators''). It is proved that ${\bf K}$ has the CSCP, using the second author's previous result that ${\bf K}_0$ has this property. A new proof is given for the result (due to E. Kirchberg) that ${\bf K}_0$ (and hence ${\bf K}$) fails the CSEP. It remains an open question if ${\bf K}$ has the MSEP; it is proved this is equivalent to whether ${\bf K}_0$ has this property. A new Banach space concept, Extendable Local Reflexivity (ELR), is introduced to study this problem. Further complements and open problems are discussed.Comment: 71 pages, AMSTe

Constrained Type Families

We present an approach to support partiality in type-level computation without compromising expressiveness or type safety. Existing frameworks for type-level computation either require totality or implicitly assume it. For example, type families in Haskell provide a powerful, modular means of defining type-level computation. However, their current design implicitly assumes that type families are total, introducing nonsensical types and significantly complicating the metatheory of type families and their extensions. We propose an alternative design, using qualified types to pair type-level computations with predicates that capture their domains. Our approach naturally captures the intuitive partiality of type families, simplifying their metatheory. As evidence, we present the first complete proof of consistency for a language with closed type families.Comment: Originally presented at ICFP 2017; extended editio

About Hrushovski and Loeser's work on the homotopy type of Berkovich spaces

Those are the notes of the two talks I gave in april 2013 in St-John (US Virgin Islands) during the Simons Symposium on non-Archimedean and tropical geometry. They essentially consist of a survey of Hrushovski and Loeser's work on the homotopy type of Berkovich spaces; the last section explains how the author has used their work for studying pre-image of skeleta.Comment: 31 pages. This text will appear in the Proceedings Book of the Simons Symposium on non-Archimedean and tropical geometry (april 2013, US Virgin Islands). I've taken into account the remarks and suggestion of the referee

An index formula for perturbed Dirac operators on Lie manifolds

International audienc