Static Typing of Complex Presence Constraints in Interfaces

Many functions in libraries and APIs have the notion of optional parameters, which can be mapped onto optional properties of an object representing those parameters. The fact that properties are optional opens up the possibility for APIs and libraries to design a complex "dependency logic" between properties: for example, some properties may be mutually exclusive, some properties may depend on others, etc. Existing type systems are not strong enough to express such dependency logic, which can lead to the creation of invalid objects and accidental usage of absent properties. In this paper we propose TypeScriptIPC: a variant of TypeScript with a novel type system that enables programmers to express complex presence constraints on properties. We prove that it is sound with respect to enforcing complex dependency logic defined by the programmer when an object is created, modified or accessed

Static Typing of Complex Presence Constraints in Interfaces (Artifact)

This artifact is based on TypeScriptIPC, a statically typed programming language with interfaces in which complex presence constraints can be defined. This enables developers to express inter-property constraints on interface properties. The need for these inter-property constraints stems from web APIs, which often impose a complex "dependency logic" between properties. For example, some properties may be mutually exclusive, or the presence of a property may depend on the presence of others, etc. TypeScriptIPC is a variant of TypeScript, in which interfaces are extended to express constraints over multiple properties, using propositional logic. This artifact contains documentation on how to build and run TypeScriptIPC, such that the code snippets from the paper can be run

Lucretia - intersection type polymorphism for scripting languages

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

Trust, but Verify: Two-Phase Typing for Dynamic Languages

A key challenge when statically typing so-called dynamic languages is the ubiquity of value-based overloading, where a given function can dynamically reflect upon and behave according to the types of its arguments. Thus, to establish basic types, the analysis must reason precisely about values, but in the presence of higher-order functions and polymorphism, this reasoning itself can require basic types. In this paper we address this chicken-and-egg problem by introducing the framework of two-phased typing. The first "trust" phase performs classical, i.e. flow-, path- and value-insensitive type checking to assign basic types to various program expressions. When the check inevitably runs into "errors" due to value-insensitivity, it wraps problematic expressions with DEAD-casts, which explicate the trust obligations that must be discharged by the second phase. The second phase uses refinement typing, a flow- and path-sensitive analysis, that decorates the first phase's types with logical predicates to track value relationships and thereby verify the casts and establish other correctness properties for dynamically typed languages

Safer typing of complex API usage through Java generics

When several incompatible implementations of a single API are in use in a Java program, the danger exists that instances from different implementations may inadvertently be mixed, leading to errors. In this paper we show how to use generics to prevent such mixing. The core idea of the approach is to add a type parameter to the interfaces of the API, and tie the classes that make up an implementation to a unique choice of type parameter. In this way methods of the API can only be invoked with arguments that belong to the same implementation. We show that the presence of a type parameter in the interfaces does not violate the principle of interface-based programming: clients can still completely abstract over the choice of implementation. In addition, we demonstrate how code can be reused between different implementations, how implementations can be defined as extensions of other implementations, and how different implementations may be mixed in a controlled and safe manner. To explore the feasibility of the approach, gauge its usability, and identify any issues that may crop up in practical usage, we have refactored a fairly large existing API-based application suite, and we report on the experience gained in the process

Class Hierarchy Complementation: Soundly Completing a Partial Type Graph

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)

A type system for components

In modern distributed systems, dynamic reconfiguration, i.e., changing at runtime the communication pattern of a program, is chal- lenging. Generally, it is difficult to guarantee that such modifications will not disrupt ongoing computations. In a previous paper, a solution to this problem was proposed by extending the object-oriented language ABS with a component model allowing the programmer to: i) perform up- dates on objects by means of communication ports and their rebinding; and ii) precisely specify when such updates can safely occur in an object by means of critical sections. However, improper rebind operations could still occur and lead to runtime errors. The present paper introduces a type system for this component model that extends the ABS type system with the notion of ports and a precise analysis that statically enforces that no object will attempt illegal rebinding

Acute: high-level programming language design for distributed computation

Existing languages provide good support for typeful programming of standalone programs. In a distributed system, however, there may be interaction between multiple instances of many distinct programs, sharing some (but not necessarily all) of their module structure, and with some instances rebuilt with new versions of certain modules as time goes on. In this paper we discuss programming language support for such systems, focussing on their typing and naming issues. We describe an experimental language, Acute, which extends an ML core to support distributed development, deployment, and execution, allowing type-safe interaction between separately-built programs. The main features are: (1) type-safe marshalling of arbitrary values; (2) type names that are generated (freshly and by hashing) to ensure that type equality tests suffice to protect the invariants of abstract types, across the entire distributed system; (3) expression-level names generated to ensure that name equality tests suffice for type-safety of associated values, e.g. values carried on named channels; (4) controlled dynamic rebinding of marshalled values to local resources; and (5) thunkification of threads and mutexes to support computation mobility. These features are a large part of what is needed for typeful distributed programming. They are a relatively lightweight extension of ML, should be efficiently implementable, and are expressive enough to enable a wide variety of distributed infrastructure layers to be written as simple library code above the byte-string network and persistent store APIs. This disentangles the language runtime from communication intricacies. This paper highlights the main design choices in Acute. It is supported by a full language definition (of typing, compilation, and operational semantics), by a prototype implementation, and by example distribution libraries

Complementarity constraints and induced innovation: Some evidence from the first IT regime

Technological search is often depicted to be random. This paper takes a different view and analyses how innovative recombinant search is triggered, how it is done and what initial conditions influence the final design of technological artefacts. We argue that complementarities (non-separabilities) play an important role as focusing devices guiding the search for new combinations. Our analysis takes the perspective of technology adopters and not that of inventors or innovators of new products. We illustrate the process of decomposition and re-composition under the presence of binding complementarity constraints with a historical case study on the establishment of the First IT Regime at the turn of the 19th century.Technological regimes, systemic innovation, adoption of technologies, complexity,information technology 1870-1930