Themes in information-rich functional programming for internet-scale data sources,”

Abstract The F# language includes a feature called "F# 3.0 Type Providers" to support the integration of internet-scale information sources into a strongly typed functional-first programming environment. In this position paper we describe the key themes in information-rich functional programming that we have observed during this work. Our contribution is to document these themes and highlight future challenges and opportunities, in the context of a recently released, practical, open-source system for informationrich functional programming. We believe that this area is rich in excellent opportunities for future language and tooling research, information-space integration and schematization techniques

Improving API Documentation for Java-like Languages

The Javadoc paradigm for displaying API documentation to users is quite popular, with similar variants existing for many mainstream languages. However, two user interface design properties of Javadoc may reduce its utility when displaying documentation for APIs that make use of inheritance and parametric polymorphism. First, Javadoc does not show a flattened view of all members of a class or interface, but rather only those defined directly in the type. Second, and as a consequence, any methods whose types contain type parameters of a superclass will always be shown in the context of the superclass. That is, if the method C.m returns type T, subclasses of C will always see this parent signature, even if they instantiate T to a concrete type such as Integer. We show that this situation arises often in some libraries, and present the results of a study that measures the usability consequences of these two Javadoc design decisions. Our results show that a user interface that shows instantiated type parameters for members is preferred over one that presents type parameters in the Javadoc style. 1

CZ: Multiple Inheritance Without Diamonds

Multiple inheritance has long been plagued with the “diamond” inheritance problem, leading to solutions that restrict expressiveness, such as mixins and traits. Instead, we address the diamond problem directly, considering two difficulties it causes: ensuring a correct semantics for object initializers, and typechecking multiple dispatch in a modular fashion—the latter problem arising even with multiple interface inheritance. We show that previous solutions to these problems are either unsatisfactory or cumbersome, and suggest a novel approach: supporting multiple inheritance but forbidding diamond inheritance. Expressiveness is retained through two features: a “requires ” construct that provides a form of subtyping without inheritance (inspired by Scala [40]), and a dynamically-dispatched “super ” call similar to that found in traits. Through examples, we illustrate that inheritance diamonds can be eliminated via a combination of “requires ” and ordinary inheritance. We provide a sound formal model for our language and demonstrate its modularity and expressiveness