Lambda the Ultimate

We seem to be in denial that our industry is maturing, we are losing our elders, some of us don’t code any more and many of our new things are really good ideas from 20 or more years ago. Some good old ideas reappear because the technology is now available to commercially exploit them; others become popular because they provide a better approach to solving a particular problem. Reinvention and improvement of good old ideas is both scholarly and sound engineering provided the prior art is cited and explained as opposed to hyped or even patented. This means we need to look for the important small improvements and not just the big bang!

Nothing remarkably new in this article, but you might want to take a look. The article was inspired by The Next Move in Programming: A Conversation with Sun's Victoria Livschitz. Victoria Livschitz's ideas were discussed here in the past.

This seems to be an introductory ("aimed specifically at non-theoreticians") set of articles on OO type theory. The author is Tony Simons and the articles were all published in the Journal of Object Technology.

1. Perspectives on Type Compatibility (pdf)
2. The Scratch-Built Typechecker (pdf)
3. Object Encodings and Recursion (pdf)
4. Object Types and Subtyping (pdf)
5. Axioms, Assertions and Subtyping (pdf)
6. The Subtyping Inquisition (pdf)
7. A Class is a Family of Types (pdf)
8. Classification and Inheritance (pdf)
9. Inheritance and Self-Reference (pdf)
10. Method Combination and Super-Reference (pdf)
11. Adding Class Types to Object Implementations (pdf)
12. Building the Class Hierarchy (pdf)
13. Template Classes and Genericity (pdf)
14. Modification and Objects like Myself (pdf)
15. Mixins and the Superclass Interface (pdf)
16. Rules of Extension and the Typing of Inheritance (pdf)
17. Multiple Inheritance and the Resolution of Inheritance Conflicts (pdf)
18. Polymorphism Through the Looking Glass (pdf)
19. The Proliferation of Parameters (pdf)
20. The Modular Checking of Classtypes (pdf)

If I've made a mistake above, try A Simons's bibliography or here.

This seems like a nice summary of various approaches, and provides an interesting prespective on prototype based languages in general and on Javascript in particular. Some of the libraries mentioned were discussed here before.

It is tempting to compare this to various documents trying to show "how to add objects to Scheme/Haskell/etc." The solutions are rather similar...

Dynamic subtype tests are frequent operations in Java programs. Naive implementations can be costly in space and running time. The techniques that have been proposed to reduce these costs are either restricted in their ability to cope with dynamic class loading or may suffer from pathological performance degradation penalizing certain programming styles. We present R&B, a subtype test algorithm designed for time and space constrained environments such as Real-Time Java which require predictable running times, low space overheads and dynamic class loading. Our algorithm is constant-time, requires an average of 10.8 bytes per class of memory and has been shown to yield an average 2.5% speedup on a production virtual machine. The Real-Time Specification for Java requires dynamic scoped memory access checks on every reference assignment. We extend R&B to perform memory access checks in constant-time.

I don't recall this paper or this subject being discussed here.

Also see this paper and this presentation.

More on John on the wiki page dedicated to his memory.

Generalized algebraic data types (GADTs) have received much attention recently in the functional programming community. They generalize the type-parameterized datatypes of ML and Haskell by permitting constructors to produce different type-instantiations of the same datatype. GADTs have a number of applications, including strongly-typed evaluators, generic pretty-printing, generic traversals and queries, and typed LR parsing. We show that existing object-oriented programming languages such as Java and C# can express GADT definitions, and a large class of GADT-manipulating programs, through the use of generics, subclassing, and virtual dispatch. However, some programs can be written only through the use of redundant run-time casts. We propose a generalization of the type constraint mechanisms of C# and Java to avoid the need for such casts, present a Visitor pattern for GADTs, and describe a switch construct as an alternative to virtual dispatch on datatypes. We formalize both extensions and prove a type soundness result.

I've been waiting for awhile for this paper to be available online.

This paper is, of course, related to the other items posted here about GADTs. The examples in the introduction might be somewhat relevant to the recent discussion about the static versus dynamic features of Java, and its type system.

The papers presented at the International Workshop on Software Factories (held at OOPSLA 2005) are avialable online as well.

Io is small, pure object oriented, prototype-based programming language. The ideas in Io are mostly inspired by Smalltalk (all values are objects), Self, NewtonScript and Act1 (prototype-based differential inheritance, actors and futures for concurrency), LISP (code is a runtime inspectable/modifiable tree) and Lua (small, embeddable).

The paper and slides are available here.

When the tutor said that Smalltalk has no case-statement, he meant it has no case-statement in the base class library.

Wiki page that shows you how to write a case construct with Smalltalk's surprisingly versatile syntax. Here's what it looks like:

aValue switch
   case: [matchCode1] then: [actionCode1];
   case: [matchCode2] then: [actionCode2];
   ...
   default: [otherCode].

ContextL is a CLOS extension for Context-oriented Programming. Currently, there is no documentation available, but you can find a small test case in the distribution and an introduction to ContextL's features in a first overview paper.

The paper says:

We present ContextL,a language extension for the Common Lisp Object System that allows for Context-oriented Programming. It provides means to associate partial class and method definitions with layers and to activate such layers in the control flow of a running program. When a layer is activated, the partial definitions become part of the program until this layer is deactivated. This has the effect that the behavior of a program can be modified according to the context of its use without the need to mention such context dependencies in the affected base program. We illustrate these ideas by describing a way to a)provide different UI views on the same object while b)keeping the conceptual simplicity of OOP that objects know themselves how to behave, in this case how to display themselves. These seemingly contradictory goals can be achieved by separating out class definitions into separate layers instead of separating out the display code into different classes.

Sounds kinda like AOP to me. It intriguings, anyway.