Lambda the Ultimate - Object-Functional

Generics of a Higher Kind

Thu, 20 Dec 2007 14:54:02 -0500

Generics of a Higher Kind. Adriaan Moors, Frank Piessens, and Martin Odersky.

With Java 5 and C# 2.0, first-order parametric polymorphism was introduced in mainstream object-oriented programming languages under the name of generics. Although the first-order variant of generics is very useful, it also imposes some restrictions: it is possible to abstract over a type, but the resulting type constructor cannot be abstracted over. This can lead to code duplication. We removed this restriction in Scala, by allowing type constructors as type parameters and abstract types. This paper presents the design and implementation of the resulting type constructor polymorphism. It combines type constructor polymorphism with implicit parameters to yield constructs similar to, and at times more expressive than, Haskell’s constructor type classes. The paper also studies interactions with other object-oriented language constructs, and discusses the gains in expressiveness.

Many readers will already be aware that Scala has added support for higher-kinded generics, related to Haskell's type constructor classes. I believe Scala is the first language to provide this capability in an OO "generics" framework. This ECOOP submission presents this work, with many practical examples.

(Consider this penance for my last post...)

OCaml Light: A Formal Semantics For a Substantial Subset of the Objective Caml Language

Mon, 26 Nov 2007 13:33:45 -0500

OCaml Light: a formal semantics for a substantial subset of the Objective Caml language.

OCaml light is a formal semantics for a substantial subset of the Objective Caml language. It is written in Ott, and it comprises a small-step operational semantics and a syntactic, non-algorithmic type system. A type soundness theorem has been proved and mechanized using the HOL-4 proof assistant, thereby ensuring that the proof is free from errors. To ensure that the operational semantics accurately models Objective Caml, an executable version of the semantics has been created (and proved equivalent in HOL to the original, relational version) and tested on a number of small test cases.

Note that while we have tried to make the semantics accurate, we are not part of the OCaml development team - this is in no sense a normative specification of the implemented language.

From a team including Peter Sewell (Acute, HashCaml, Ott).

I continue to believe that things are heating up nicely in mechanized metatheory, which, in the multicore/multiprocessor world in which we now live, is extremely good news.

Metaprogramming with Traits

Mon, 13 Aug 2007 11:55:16 -0400

Metaprogramming with Traits, Aaron Turon and John Reppy. ECOOP 2007

In many domains, classes have highly regular internal structure. For example, so-called business objects often contain boilerplate code for mapping database fields to class members. The boilerplate code must be repeated per-field for every class, because existing mechanisms for constructing classes do not provide a way to capture and reuse such member-level structure. As a result, programmers often resort to ad ho code generation. This paper presents a lightweight mechanism for specifying and reusing member-level structure in Java programs. The proposal is based on a modest extension to traits that we have termed trait-based metaprogramming. Although the semantics of the mechanism are straightforward, its type theory is difficult to reconcile with nominal subtyping. We achieve reconciliation by introducing a hybrid structural/nominal type system that extends Java's type system. The paper includes a formal calculus defined by translation to Featherweight Generic Java.

This paper explains how to scratch an itch I've had for a long, long time -- uniformly generating groups of fields and methods, including computation of the field/method names. Something like this would be quite useful in an ML-like language's module system, too.

Python in Pardus Linux

Tue, 19 Jun 2007 18:55:33 -0400

Pardus Linux is a case study of functional Python. It's a Linux distribution built from semi-scratch, the main focii being package management and init subsystems - places where C and shell script make poor sense. A funded group has finally tackled these issues.

A package management software deals a lot with sets, lists, and dependency graphs....We have extensively used functional operators (map, filter, reduce) and list comprehensions, even metaclasses are used in a few places.

Someone nudge Guido. Scheme or Oz might have been the better choice, but give them credit. They admit frankly to social acceptance issues.

Combining Total and Ad Hoc Extensible Pattern Matching in a Lightweight Language Extension

Thu, 03 May 2007 06:40:27 -0400

Combining Total and Ad Hoc Extensible Pattern Matching in a Lightweight Language Extension. Don Syme, Gregory Neverov and James Margetson.

Pattern matching of algebraic data types (ADTs) is a standard feature in typed functional programming languages but it is well known that it interacts poorly with abstraction. While several partial solutions to this problem have been proposed, few have been implemented or used. This paper describes an extension to the .NET language F# called ``Active Patterns'', which supports pattern matching over abstract representations of generic heterogeneous data such as XML and term structures, including where these are represented via object models in other .NET languages. Our design is the first to incorporate both ad hoc pattern matching functions for partial decompositions and ``views'' for total decompositions, and yet remains a simple and lightweight extension. We give a description of the language extension along with numerous motivating examples. Finally we describe how this feature would interact with other reasonable and related language extensions: existential types quantified at data discrimination tags, GADTs, and monadic generalizations of pattern matching.

Quite related to the recent discussions of the relationships between libraries, frameworks and language features.

A Real-World Use of Lift, a Scala Web Application Framework

Thu, 22 Mar 2007 12:06:24 -0400

A Real-World Use of Lift

Well, lift is actually being used in production. I converted a Rails app to lift and it was a very interesting experience...

Then we did some benchmarking. For single request processing, the lift code, running inside Tomcat, ran 4 times faster than the Rails code running inside Mongrel. However, the CPU utilization was less than 5% in the lift version, where it was 100% of 1 CPU (on a dual core machine) for the Rails version. For multiple simultaneous requests being made from multiple machines, we're seeing better than 20x performance of the lift code versus the Rails code with 5 Mongrel instances. Once again, the lift code is not using very much CPU and the Rails code is pegging both CPUs.

In terms of new features, we've been able to add new features to the lift code with fewer defects than with the Rails code. Our Rails code had 70% code coverage. We discovered that anything shy of 95% code coverage with Rails means that type-os turn into runtime failures. We do not have any code coverage metrics for the lift code, but we have seen only 1 defect that's been checked in in the 2 weeks since we started using lift (vs. an average of 1 defect per checkin with the Rails code.)

So, yes, I'm pimping my own framework, and yes, I'm able to do with lift what guys like DHH are able to do with Rails, so the comparison is, in some ways, unfair.

On the other hand, Scala and lift code can be as brief and expressive as Ruby code. lift offers developers amazing productivity gains vs. traditional Java web frameworks, just as Rails does. On the other hand, lift code scales much better than Rails code. lift code is type-safe and the compiler becomes your friend (this does not mean you should not write tests, but it means that your tests can focus on the algorithm rather than making sure there are no type-os in variable and method names.)

I promise that "Dave Pollak" is not a pseudonym for "Paul Snively."

Update: I guess the self-deprecating humor hasn't worked, some 400+ reads later. Although the caveat that Dave offers about trying to objectively compare his own framework with Ruby on Rails is well-taken, I think that this nevertheless is an important marker in applying a very PLT-driven language and framework, Scala and lift, to a very realistic application, especially given that it's a rewrite from a currently-popular language and framework, Ruby and Rails. We admitted proponents of static typing and weird languages are constantly being asked for this sort of thing, and while it's doubtful that this adds anything to the PLT discussion per se—at least until we have a chance to dig into lift and see how Scala's design uniquely supports it—I thought people might find the Scala connection worth commenting on.

Threads in JavaScript?

Tue, 13 Feb 2007 19:43:50 -0500

Threads in JavaScript? "Over your dead body," says Brendan.

But Neil Mix begs to differ -- they're already there!

Neil's latest blog post presents a cool hack combining JavaScript 1.7's generators with trampolined style to implement very lightweight cooperative threads.

The implementation weighs in at a breathtakingly small 4k.

Ralf Lammel: Stop dysfunctional programming

Sat, 27 Jan 2007 05:46:19 -0500

40 years after the invention of OO, I am ready to appreciate objects quite a bit because I can use them in combination with functional programming. Naturally, I call this mix functional OO programming. (I don’t quite count functional objects in C++ or ‘functors’ in Java, a misnomer BTW, as functional programming.)

Ralf lists several of his papers that apply the notion of functional OO programming. He also shares his wish list for future versions of C#.

Matching Objects With Patterns

Thu, 04 Jan 2007 15:01:08 -0500

Matching Objects With Patterns. Burak Emir, Martin Odersky, and John Williams.

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/typecasts, 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.

A Core Calculus for Scala Type Checking

Fri, 14 Jul 2006 08:01:14 -0400

A Core Calculus for Scala Type Checking, is a new paper by the Scala team.

Abstract. We present a minimal core calculus that captures interesting constructs of the Scala programming language: nested classes, abstract types, mixin composition, and path dependent types. We show that the problems of type assignment and subtyping in this calculus are decidable.

The paper revolves around the question of decidability of type checking in Scala. The following quote summarizes the background of this question.

Scala’s approach to component modeling is based on three programming language constructs: modular mixin composition, abstract type members, and explicit self-types. All three have been studied in the vObj calculus. A key concept of the vObj calculus, path-dependent types, is also present in Scala. However, some other constructions of vObj do not correspond to Scala language constructs. In particular, vObj has first-class classes which can be passed around as values, but Scala has not.
First-class classes were essential in establishing an encoding of F<: in vObj, which led to a proof of undecidability of vObj by reduction to the same property in F<:. However, since Scala lacks first-class classes, the undecidability result for the calculus does not imply that type checking for the programming language is undecidable.

Ehud: Given current interest in Scala and its more or less unique (don't want to raise controversy here) position as being both a functional and an OO language, furthermore being much more than a toy language, would it be a good idea to give Scala a place in the Spotlight section?

Event-Based Programming without Inversion of Control

Wed, 12 Jul 2006 18:00:58 -0400

Event-Based Programming without Inversion of Control. Philipp Haller and Martin Odersky.

Scala is different from other concurrent languages in that it contains no language support for concurrency beyond the standard thread model offered by the host environment. Instead of specialized language constructs we rely on Scala's general abstraction capabilities to define higher-level concurrency models. In such a way, we were able to define all essential operations of Erlang's actor-based process model in the Scala library.

However, since Scala is implemented on the Java VM, we inherited some of the deficiencies of the host environment when it comes to concurrency, namely low maximum number of threads and high context-switch overhead. In this paper we have shown how to turn this weakness into a strength. By defining a new event-based model for actors, we could increase dramatically their efficiency and scalability. At the same time, we kept to a large extent the programming model of thread-based actors, which would not have been possible if we had switched to a traditional event-based architecture, because the latter causes an inversion of control.

(There's not really a proper abstract. The above is from the conclusion.)

I enjoyed this paper. It's a quick read and a nice demonstration of some of Scala's cool features. It's also a good example of using exceptions as delimited control operators, and in fact the one substantial restriction is imposed by the lack of the more powerful operators. They use Scala's type system to reduce the burden of this restriction, however, since they're able to state that a particular statement never returns normally (and thus must not be followed by more statements).

Those interested in the language/library boundary will also find it interesting for this reason:

The techniques presented in this paper are a good showcase of the increased flexibility offered by library-based designs. It allowed us to quickly address problems with the previous thread-based actor model by developing a parallel class hierarchy for event-based actors. Today, the two approaches exist side by side. Thread-based actors are still useful since they allow returning from a receive operation. Event-based actors are more restrictive in the programming style they allow, but they are also more efficient.

They have some fairly impressive empirical scalability results as well.

JavaScript 2 and the Future of the Web

Thu, 01 Jun 2006 12:39:33 -0400

Brendan Eich, JavaScript 2 and the Future of the Web, XTech 2006

Motivation:

Fix problems in JS1 that bug people daily

A type system to enforce invariants

Programming in the large

Support bootstrapping and metaprogramming

Brendan Eich presented these slides recently at a conference on the future of web technology.

Typed Concurrent Programming with Logic Variables

Fri, 05 May 2006 04:33:38 -0400

Typed Concurrent Programming with Logic Variables

We present a concurrent higher-order programming language called Plain and a
concomitant static type system. Plain is based on logic variables and computes
with possibly partial data structures. The data structures of Plain are procedures, cells, and records. Plain's type system features record-based subtyping, bounded existential polymorphism, and access modalities distinguishing between reading and writing.

You may want to compare this with The Oz Programming Model (OPM), which

... is a concurrent programming model subsuming higher-order functional and object-oriented programming as facets of a general model. This is particularly interesting for concurrent object-oriented programming, for which no comprehensive formal model existed until now. The model can be extended so that it can express encapsulated problem solvers generalizing the problem solving capabilities of constraint logic programming.

Another paper on OPM is The Operational Semantics of Oz.

In short, the model of Plain is based on that of Oz with the main differences being:

Plain statically types programs using a type system with subtyping, while Oz is latently typed.
Therefore Plain chooses to drop support for unification in favor of a single-assignment operation.

OCaml 3.0.9

Wed, 09 Nov 2005 22:34:50 -0500

The most recent version of Objective Caml is 3.09.0. It was released on 2005-10-27.

Some of the highlights in release 3.09 are:

Introduction of private row types, for abstracting the row variable in object and variant types.
Added warnings Y and Z for local variables that are bound but never used.
More portable implementation of the -pack option to ocamlopt.

For more information, please consult the comprehensive list of changes.

Haskell's overlooked object system

Fri, 16 Sep 2005 08:30:36 -0400

A "major new release" from Oleg Kiselyov and Ralf Lämmel:

In a first phase, we demonstrate how far we can get with object-oriented functional programming, if we restrict ourselves to plain Haskell~98. In the second and major phase, we systematically substantiate that Haskell~98, with some common extensions, supports all the conventional OO features plus more advanced ones, including first-class lexically scoped classes, implicitly polymorphic classes, flexible multiple inheritance, safe downcasts and safe co-variant arguments. Haskell indeed can support width and depth, structural and nominal subtyping. We address the particular challenge to preserve Haskell's type inference even for objects and object-operating functions. Advanced type inference is a strength of Haskell that is worth preserving. Many of the features we get "for free": the type system of Haskell turns out to be a great help and a guide rather than a hindrance.

You can download the paper and OOHaskell from here.