When considering the past or the future, dear apprentice, be mindful of the present. If, while considering the past, you become caught in the past, lost in the past, or enslaved by the past, then you have forgotten yourself in the present. If, while considering the future, you become caught in the future, lost in the future, or enslaved by the future, then you have forgotten yourself in the present. Conversely, when considering the past, if you do not become caught, lost, or enslaved by the past, then you have remained mindful of the present. And if, when considering the future, you do not become caught, lost, or enslaved in the future, then you have remained mindful of the present. [14] Programmers in the real world wrestle everyday to overcome the impedance mismatch between relational data, objects, and XML. We have been working on solving this problem for the past ten years by applying principles from functional programming, in particular monads and comprehensions. By viewing data as monads and formulating queries as comprehensions, it becomes possible to unify the three data models and their corresponding programming languages instead of considering each as a separate special case. To actually bring this within the reach of mainstream programmers we have worked tirelessly on transferring functional programming technology from pure Haskell, via Cω to the upcoming versions of C ♯ 3.0 and Visual Basic 9 and the LINQ framework. Functional programming has finally reached the masses, except that it is called Visual Basic instead of Lisp,

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.

This report contains the papers presented at FTfJP’08: the 10th workshop on

ABSTRACT. We report on our experiences in redesigning Scala’s collection libraries, focussing on the role that type systems play in keeping software architectures coherent over time. Type systems can make software architecture more explicit but, if they are too weak, can also cause code duplication. We show that code duplication can be avoided using two of Scala’s type constructions: higher-kinded types and implicit parameters and conversions. 1

Proefschrift voorgedragen tot het behalen van het doctoraat in de ingenieurswetenschappen door

Wildcard types enrich the types expressible in Java, and extend the set of typeable Java programs. Syntactic models and proofs of soundness for type systems related to Java wildcards have been suggested in the past, however, the semantics of wildcards has not yet been studied. In this paper we propose a semantic model for Java wildcards, inspired by work on semantic subtyping, which traditionally interprets types as sets of possible values. To easily reflect the nominal type system of Java, our model is defined in terms of runtime types (closed class types) rather than the structure of the runtime values themselves. To reflect the variance introduced by wildcards, our model interprets types as sets of such closed class types. Having defined our model, we employ a standard semantic notion of subtyping. We show soundness of syntactic subtyping with respect to the semantic version, and demonstrate that completeness fails in the general case. We identify a restricted (but nonetheless rich) type language for which the syntactic notion of subtyping is both sound and complete. 1.

The modularity of aspect-oriented programming (AOP) has been a controversial issue. To investigate this issue compared with object-oriented programming (OOP), we propose a simple language providing AOP mechanisms, which are enhanced traditional OOP mechanisms. We also present its formal system and then show that programs in this language can be only mostly modularly (i.e. separately) typechecked and compiled. We mention a source of this unmodularity and discuss whether or not it is appropriate to claim that AOP breaks modularity compared with OOP.