Lambda the Ultimate

There's a new document on the incompatibilities between ECMAScript Edition 3 and the proposed Edition 4. Given the recent controversy in the blogosphere and the degree of interest in last week's discussion of the proposed ES4, this document may be of interest to LtUers.

It's also interesting to think of conservative extension not as an all-or-nothing property, but to judge incompatibilities in terms of their impact. This document attempts to enumerate and classify the different ways the proposed ES4 spec conflicts with the specification of ES3.

(One last note: there's a new pre-release of the reference implementation available, with binaries for all major platforms. Check it out!)

Vaidas Gasiunas, Mira Mezini, Klaus Ostermann. Dependent Classes. OOPSLA'07.

Virtual classes allow nested classes to be refined in subclasses. In this way nested classes can be seen as dependent abstractions of the objects of the enclosing classes. Expressing dependency via nesting, however, has two limitations: Abstractions that depend on more than one object cannot be modeled and a class must know all classes that depend on its objects. This paper presents dependent classes, a generalization of virtual classes that expresses similar semantics by parameterization rather than by nesting. This increases expressivity of class variations as well as the flexibility of their modularization. Besides, dependent classes complement multimethods in scenarios where multi-dispatched abstractions rather than multi-dispatched methods are needed. They can also be used to express more precise signatures of multimethods and even extend their dispatch semantics. We present a formal semantics of dependent classes and a machine-checked type soundness proof in Isabelle/HOL, the first of this kind for a language with virtual classes and path-dependent types.

I enjoyed this talk at OOPSLA, although I was not able to see the end, and I enjoyed the paper even more. There's been so much work on virtual classes in recent years, and while I very clearly see a strong practical motivation for this work, I admit that I find it difficult to keep track of the technical trade-offs between different approaches. This, plus the persistent limitations mentioned in the abstract, lends some of the papers an unfortunately tedious feel (to me). I find this work refreshing, since it introduces a substantial new idea in this area. (And of course, one of the authors posts here regularly...)

FringeDC is a group in Washington DC interested in fringe programming languages such as
Lisp, Erlang, Haskell, Prolog, etc.

Web Site:
http://www.lisperati.com/fringedc.html

Nov 6th Meeting Info:
http://www.lisperati.com/nov10.html

Hi Folks

I was just having a discussion with a friend and this question might not seem logical but - just like any code structure can be represented by closures and any control flow can be modelled by continuations, is there any type system in which all type systems can be represented ? Does this concept even make sense ?