402 research outputs found

    Practical Datatype Specializations with Phantom Types and Recursion Schemes

    Get PDF
    Datatype specialization is a form of subtyping that captures program invariants on data structures that are expressed using the convenient and intuitive datatype notation. Of particular interest are structural invariants such as well-formedness. We investigate the use of phantom types for describing datatype specializations. We show that it is possible to express statically-checked specializations within the type system of Standard ML. We also show that this can be done in a way that does not lose useful programming facilities such as pattern matching in case expressions.Comment: 25 pages. Appeared in the Proc. of the 2005 ACM SIGPLAN Workshop on M

    Class Hierarchy Complementation: Soundly Completing a Partial Type Graph

    Get PDF
    We present the problem of class hierarchy complementa- tion: given a partially known hierarchy of classes together with subtyping constraints (“A has to be a transitive sub- type of B”) complete the hierarchy so that it satisfies all con- straints. The problem has immediate practical application to the analysis of partial programs—e.g., it arises in the process of providing a sound handling of “phantom classes” in the Soot program analysis framework. We provide algorithms to solve the hierarchy complementation problem in the single inheritance and multiple inheritance settings. We also show that the problem in a language such as Java, with single in- heritance but multiple subtyping and distinguished class vs. interface types, can be decomposed into separate single- and multiple-subtyping instances. We implement our algorithms in a tool, JPhantom, which complements partial Java byte- code programs so that the result is guaranteed to satisfy the Java verifier requirements. JPhantom is highly scalable and runs in mere seconds even for large input applications and complex constraints (with a maximum of 14s for a 19MB binary)

    First-Class Subtypes

    Full text link
    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.Comment: In Proceedings ML 2017, arXiv:1905.0590

    Subtyping somatic tinnitus: a cross-sectional UK cohort study of demographic, clinical and audiological characteristics

    Get PDF
    Somatic tinnitus is the ability to modulate the psychoacoustic features of tinnitus by somatic manoeuvres. The condition is still not fully understood and further identification of this subtype is essential, particularly for the purpose of establishing protocols for both its diagnosis and treatment. This study aimed to investigate the characteristics of somatic tinnitus within a large UK cohort using a largely unselected sample. We believe this to be relatively unique in comparison to current literature on the topic. This was investigated by using a total of 608 participant assessments from a set of recognised tinnitus and audiology measures. Results from a set of chi-square tests of association found that amongst the individuals with somatic tinnitus, a higher proportion had pulsatile tinnitus (different from heartbeat), were under the age of 40, reported variation in the loudness of their tinnitus and reported temporomandibular joint (TMJ) disorder. The same pattern of results was confirmed using a multivariate analysis of the data based on logistic regression. These findings have strong implications towards the profiling of somatic tinnitus as a distinct subtype of general tinnitus

    Linear Haskell: practical linearity in a higher-order polymorphic language

    Get PDF
    Linear type systems have a long and storied history, but not a clear path forward to integrate with existing languages such as OCaml or Haskell. In this paper, we study a linear type system designed with two crucial properties in mind: backwards-compatibility and code reuse across linear and non-linear users of a library. Only then can the benefits of linear types permeate conventional functional programming. Rather than bifurcate types into linear and non-linear counterparts, we instead attach linearity to function arrows. Linear functions can receive inputs from linearly-bound values, but can also operate over unrestricted, regular values. To demonstrate the efficacy of our linear type system - both how easy it can be integrated in an existing language implementation and how streamlined it makes it to write programs with linear types - we implemented our type system in GHC, the leading Haskell compiler, and demonstrate two kinds of applications of linear types: mutable data with pure interfaces; and enforcing protocols in I/O-performing functions

    Lucretia - intersection type polymorphism for scripting languages

    Full text link
    Scripting code may present maintenance problems in the long run. There is, then, the call for methodologies that make it possible to control the properties of programs written in dynamic languages in an automatic fashion. We introduce Lucretia, a core language with an introspection primitive. Lucretia is equipped with a (retrofitted) static type system based on local updates of types that describe the structure of objects being used. In this way, we deal with one of the most dynamic features of scripting languages, that is, the runtime modification of object interfaces. Judgements in our systems have a Hoare-like shape, as they have a precondition and a postcondition part. Preconditions describe static approximations of the interfaces of visible objects before a certain expression has been executed and postconditions describe them after its execution. The field update operation complicates the issue of aliasing in the system. We cope with it by introducing intersection types in method signatures.Comment: In Proceedings ITRS 2014, arXiv:1503.0437
    corecore