Staging with class: a specification for typed template Haskell

Multi-stage programming using typed code quotation is an established technique for writing optimizing code generators with strong type-safety guarantees. Unfortunately, quotation in Haskell interacts poorly with type classes, making it difficult to write robust multi-stage programs. We study this unsound interaction and propose a resolution, staged type class constraints, which we formalize in a source calculus λ ⇒ that elaborates into an explicit core calculus F . We show type soundness of both calculi, establishing that well-typed, well-staged source programs always elaborate to well-typed, well-staged core programs, and prove beta and eta rules for code quotations. Our design allows programmers to incorporate type classes into multi-stage programs with confidence. Although motivated by Haskell, it is also suitable as a foundation for other languages that support both overloading and quotation.

Implementation of a Graphic Interface Development Tool for Prolog

The work examines the current problems of the spread of use of logical programming in the development of commercial multi-platform software applications, tools for convenient development of a modern graphical interface to the logical programs. Libraries with similar concepts of use have been analyzed and described. The purpose of the proposed concept, which is implemented as an open source library, is described, and the advantages of the proposed tools over similar existing tools are indicated. The main feature and advantage of the proposed concept is the implementation of Prolog business logic and interface by means of JavaScript usage of child processes. The proposed concept of interface to Prolog takes full advantage of the possibilities provided by async await. A framework library has been created for the use of Logic Programming in graphical interface development without losses in the application performance. The paper describes the proposed concept and the developed framework (library). The ways to further improve the possibilities for expanding the purpose of the implemented library were identified. The directions of further simplification for programmers of integration of the graphic interface to logical programs have been defined. A significant advantage of the proposed tool is the easy-to-use functions to wrap and control the correctness of requests to the Prolog. The main goal of the library is to create an environment for the Prolog developers where they can create any type of software, which is meant to be user friendly, fast, and cross platform using modern and flexible. This concept also tries to solve disadvantages and architectural problems that were found in other libraries. The safety of library functionality has been analyzed. The concept of potential horizontal application scalability is described. Conclusions and future of libraries were introduced, in which the usage of TypeScript for type-safety and avoidance of run-time errors is mentioned. Overall, the library extends the use of Prolog beyond logical programming and takes a leap forward in its progress.

Decidable Subtyping for Path Dependent Types

<p>Path dependent types form a central component of the Scala programming language. Coupled with other expressive type forms, path dependent types provide for a diverse set of concepts and patterns, from nominality to F-bounded polymorphism. Recent years have seen much work aimed at formalising the foundations of path dependent types, most notably a hard won proof of type safety. Unfortunately subtyping remains undecidable, presenting problems for programmers who rely on the results of their tools. One such tool is Dotty, the basis for the upcoming Scala 3. Another is Wyvern, a new programming language that leverages path dependent types to support both first class modules and parametric polymorphism. In this thesis I investigate the issues with deciding subtyping in Wyvern. I define three decidable variants that retain several key instances of expressiveness including the ability to encode nominality and parametric polymorphism. Wyvfix fixes types to the contexts they are defined in, thereby eliminating expansive environments. Wyvnon-μ removes recursive subtyping, thus removing the key source of expansive environments during subtyping. Wyvμ places a syntactic restriction on the usage of recursive types. I discuss the formal properties of these variants, and the implications each has for expressing the common programming patterns of path dependent types. I have also mechanized the proofs of decidability for both Wyvfix and Wyvμ in Coq.</p>

Decidable Subtyping for Path Dependent Types

<p>Path dependent types form a central component of the Scala programming language. Coupled with other expressive type forms, path dependent types provide for a diverse set of concepts and patterns, from nominality to F-bounded polymorphism. Recent years have seen much work aimed at formalising the foundations of path dependent types, most notably a hard won proof of type safety. Unfortunately subtyping remains undecidable, presenting problems for programmers who rely on the results of their tools. One such tool is Dotty, the basis for the upcoming Scala 3. Another is Wyvern, a new programming language that leverages path dependent types to support both first class modules and parametric polymorphism. In this thesis I investigate the issues with deciding subtyping in Wyvern. I define three decidable variants that retain several key instances of expressiveness including the ability to encode nominality and parametric polymorphism. Wyvfix fixes types to the contexts they are defined in, thereby eliminating expansive environments. Wyvnon-μ removes recursive subtyping, thus removing the key source of expansive environments during subtyping. Wyvμ places a syntactic restriction on the usage of recursive types. I discuss the formal properties of these variants, and the implications each has for expressing the common programming patterns of path dependent types. I have also mechanized the proofs of decidability for both Wyvfix and Wyvμ in Coq.</p>

Generic Ownership Types for Java and the Collections Framework

<p>Generic programming has turned out very useful in the development of reusable software. With the Java programming language, genericity is not only meant for reusability, but also for type-safety. Java generics constrain a container object (e.g., list, hash table) to store objects of a pre-specified data type. Nevertheless, safe programming with aliasing (multiple pointers in a program may point to the same object) is still a concern in object-oriented programming language research. A pointing object can mutate the state of the aliased object, reflecting the changes to all of the other pointers (aka aliases) thus affecting their behaviour. As programs grow larger and more complex, such changes in behaviour can be undesirable and difficult to detect and reason about. With respect to container objects, the iterator pattern critically violates encapsulation, allowing aliases to the state (and thereof the components) of its container. Object ownership is one of the well-researched paradigms in the area of alias management. Ownership types support hierarchical object encapsulation rather than the traditional class-level encapsulation. This thesis introduces an extension of Java 6 with support for ownership types as supplementary generic types. That is, Java generics are extended with the ability of carrying ownership information. This extension provides generic ownership support for all of Java; that is, all major language features are addressed so that programs can safely manage and express their aliasing properties. The resulting language is expressive enough to support common programming idioms, with little programming and runtime overhead. We evaluated the programmability of the language by refactoring a major (the most essential) portion of the Java Collections Framework. We also evaluated the performance impact of our refactoring by conducting a small micro-benchmark study to measure the performance time overhead the refactored collections may impose.</p>

Generic Ownership Types for Java and the Collections Framework

<p>Generic programming has turned out very useful in the development of reusable software. With the Java programming language, genericity is not only meant for reusability, but also for type-safety. Java generics constrain a container object (e.g., list, hash table) to store objects of a pre-specified data type. Nevertheless, safe programming with aliasing (multiple pointers in a program may point to the same object) is still a concern in object-oriented programming language research. A pointing object can mutate the state of the aliased object, reflecting the changes to all of the other pointers (aka aliases) thus affecting their behaviour. As programs grow larger and more complex, such changes in behaviour can be undesirable and difficult to detect and reason about. With respect to container objects, the iterator pattern critically violates encapsulation, allowing aliases to the state (and thereof the components) of its container. Object ownership is one of the well-researched paradigms in the area of alias management. Ownership types support hierarchical object encapsulation rather than the traditional class-level encapsulation. This thesis introduces an extension of Java 6 with support for ownership types as supplementary generic types. That is, Java generics are extended with the ability of carrying ownership information. This extension provides generic ownership support for all of Java; that is, all major language features are addressed so that programs can safely manage and express their aliasing properties. The resulting language is expressive enough to support common programming idioms, with little programming and runtime overhead. We evaluated the programmability of the language by refactoring a major (the most essential) portion of the Java Collections Framework. We also evaluated the performance impact of our refactoring by conducting a small micro-benchmark study to measure the performance time overhead the refactored collections may impose.</p>

Permchecker: a toolchain for debugging memory managers with typestate

Dynamic memory managers are a crucial component of almost every modern software system. In addition to implementing efficient allocation and reclamation, memory managers provide the essential abstraction of memory as distinct objects, which underpins the properties of memory safety and type safety. Bugs in memory managers, while not common, are extremely hard to diagnose and fix. One reason is that their implementations often involve tricky pointer calculations, raw memory manipulation, and complex memory state invariants. While these properties are often documented, they are not specified in any precise, machine-checkable form. A second reason is that memory manager bugs can break the client application in bizarre ways that do not immediately implicate the memory manager at all. A third reason is that existing tools for debugging memory errors, such as Memcheck, cannot help because they rely on correct allocation and deallocation information to work. In this paper we present Permchecker, a tool designed specifically to detect and diagnose bugs in memory managers. The key idea in Permchecker is to make the expected structure of the heap explicit by associating typestates with each piece of memory. Typestate captures elements of both type (e.g., page, block, or cell) and state (e.g., allocated, free, or forwarded). Memory manager developers annotate their implementation with information about the expected typestates of memory and how heap operations change those typestates. At runtime, our system tracks the typestates and ensures that each memory access is consistent with the expected typestates. This technique detects errors quickly, before they corrupt the application or the memory manager itself, and it often provides accurate information about the reason for the error. The implementation of Permchecker uses a combination of compile-time annotation and instrumentation, and dynamic binary instrumentation (DBI). Because the overhead of DBI is fairly high, Permchecker is suitable for a testing and debugging setting and not for deployment. It works on a wide variety of existing systems, including explicit malloc/free memory managers and garbage collectors, such as those found in JikesRVM and OpenJDK. Since bugs in these systems are not numerous, we developed a testing methodology in which we automatically inject bugs into the code using bug patterns derived from real bugs. This technique allows us to test Permchecker on hundreds or thousands of buggy variants of the code. We find that Permchecker effectively detects and localizes errors in the vast majority of cases; without it, these bugs result in strange, incorrect behaviors usually long after the actual error occurs.

Gradually structured data

Dynamically-typed languages offer easy interaction with ad hoc data such as JSON and S-expressions; statically-typed languages offer powerful tools for working with structured data, notably algebraic datatypes , which are a core feature of typed languages both functional and otherwise. Gradual typing aims to reconcile dynamic and static typing smoothly. The gradual typing literature has extensively focused on the computational aspect of types, such as type safety, effects, noninterference, or parametricity, but the application of graduality to data structuring mechanisms has been much less explored. While row polymorphism and set-theoretic types have been studied in the context of gradual typing, algebraic datatypes in particular have not, which is surprising considering their wide use in practice. We develop, formalize, and prototype a novel approach to gradually structured data with algebraic datatypes. Gradually structured data bridges the gap between traditional algebraic datatypes and flexible data management mechanisms such as tagged data in dynamic languages, or polymorphic variants in OCaml. We illustrate the key ideas of gradual algebraic datatypes through the evolution of a small server application from dynamic to progressively more static checking, formalize a core functional language with gradually structured data, and establish its metatheory, including the gradual guarantees.

Safe-by-default Concurrency for Modern Programming Languages

Modern “safe” programming languages follow a design principle that we call safety by default and performance by choice . By default, these languages enforce important programming abstractions, such as memory and type safety, but they also provide mechanisms that allow expert programmers to explicitly trade some safety guarantees for increased performance. However, these same languages have adopted the inverse design principle in their support for multithreading. By default, multithreaded programs violate important abstractions, such as program order and atomic access to individual memory locations to admit compiler and hardware optimizations that would otherwise need to be restricted. Not only does this approach conflict with the design philosophy of safe languages, but very little is known about the practical performance cost of providing a stronger default semantics. In this article, we propose a safe-by-default and performance-by-choice multithreading semantics for safe languages, which we call volatile -by-default . Under this semantics, programs have sequential consistency (SC) by default, which is the natural “interleaving” semantics of threads. However, the volatile -by-default design also includes annotations that allow expert programmers to avoid the associated overheads in performance-critical code. We describe the design, implementation, optimization, and evaluation of the volatile -by-default semantics for two different safe languages: Java and Julia. First, we present V BD-HotSpot and V BDA-HotSpot, modifications of Oracle’s HotSpot JVM that enforce the volatile -by-default semantics on Intel x86-64 hardware and ARM-v8 hardware. Second, we present S C-Julia, a modification to the just-in-time compiler within the standard Julia implementation that provides best-effort enforcement of the volatile -by-default semantics on x86-64 hardware for the purpose of performance evaluation. We also detail two different implementation techniques: a baseline approach that simply reuses existing mechanisms in the compilers for handling atomic accesses, and a speculative approach that avoids the overhead of enforcing the volatile -by-default semantics until there is the possibility of an SC violation. Our results show that the cost of enforcing SC is significant but arguably still acceptable for some use cases today. Further, we demonstrate that compiler optimizations as well as programmer annotations can reduce the overhead considerably.

Making legacy Fortran code type safe through automated program transformation

Fortran is still widely used in scientific computing, and a very large corpus of legacy as well as new code is written in FORTRAN 77. In general this code is not type safe, so that incorrect programs can compile without errors. In this paper, we present a formal approach to ensure type safety of legacy Fortran code through automated program transformation. The objective of this work is to reduce programming errors by guaranteeing type safety. We present the first rigorous analysis of the type safety of FORTRAN 77 and the novel program transformation and type checking algorithms required to convert FORTRAN 77 subroutines and functions into pure, side-effect free subroutines and functions in Fortran 90. We have implemented these algorithms in a source-to-source compiler which type checks and automatically transforms the legacy code. We show that the resulting code is type safe and that the pure, side-effect free and referentially transparent subroutines can readily be offloaded to accelerators.