Abstract. Data in object-oriented programming is organized in a hierarchy of classes. The problem of object-oriented pattern matching is how to explore this hierarchy from the outside. This usually involves classifying objects by their run-time type, accessing their members, or determining some other characteristic of a group of objects. In this paper we compare six different pattern matching techniques: object-oriented decomposition, visitors, type-tests/type-casts, typecase, case classes, and extractors. The techniques are compared on nine criteria related to conciseness, maintainability and performance. The paper introduces case classes and extractors as two new pattern-matching methods and shows that their combination works well for all of the established criteria. 1

Abstract. Generics are a very popular feature of contemporary OO languages, such as Java, C # or Scala. Their support for genericity is lacking, however. The problem is that they only support abstracting over proper types, and not over generic types. This limitation makes it impossible to, e.g., define a precise interface for Iterable, a core abstraction in Scala’s collection API. We implemented “type constructor polymorphism ” in Scala 2.5, which solves this problem at the root, thus greatly reducing the duplication of type signatures and code. 1

Abstract not found

When developing a large software program, it is useful to decompose the program into smaller parts and to reuse them in different contexts. Many modern programming languages provide some forms of module systems to facilitate such factoring of programs. The ML module system is well-known for its flexibility in program structuring. A programmer can factor programs into hierarchy using nested structures and can define functors, which are functions over modules, to reuse program codes. Moreover, signatures, which represent types of modules, allow the programmer to control abstraction of modules. In spite of this flexibility, modules cannot be defined recursively in ML, since dependencies between modules must accord with the order of definitions. A complex program may be naturally decomposed into recursive modules. Yet, this constraint of ML will force the programmer to consolidate conceptually separate components into a single module, intruding on modular programming. Introducing recursive modules is a natural way out of this predicament. Existing proposals, however, vary in expressiveness and verbosity. In this paper, we propose a type system for recursive modules, which can infer their signatures. Opaque signatures can also be given explicitly, to provide type abstraction either inside or outside the recursion. The type system is decidable, and is sound for a call-by-value semantics.

Featherweight Java has been highly successful for reasoning about type systems in Java. However, it is not suited to formalising flow-sensitive type systems. Such systems differ from the norm by allowing variables to have different types at different program points. A large number of problems are naturally expressed in this way. For example, reasoning about non-null types requires retyping a variable v after a condition v!=null. Other examples include those from data flow analysis, security flow analysis, and more. In this paper, we present Featherweight Intermediate Java (FIJ) — an imperative formalisation of Java. A key advantage of FIJ is support for control-flow arising from exceptions. We formalise the syntax, semantics, and typing process of FIJ. We also discuss what it means for a FIJ program to be type-safe, and detail the proof structure required to show this (which differs considerably from traditional subjectreduction style proofs). 1.