Lambda the Ultimate

If you are in Denmark in September you should attend. If not, raise a glass to salute what is now abundantly clear: FPLs are conquering the ("real") world.

Due to issues with spam accounts I have suspended the creation of new accounts. New members cannot sign up for an account at the moment. I apologize for the inconvenience.

Koka is a function-oriented programming language that seperates pure values from side-effecting computations, where the effect of every function is automatically inferred. Koka has many features that help programmers to easily change their data types and code organization correctly, while having a small language core with a familiar JavaScript like syntax.

Koka extends the idea of using row polymorphism to encode an effect system and the relations between them. Daan Leijen is the primary researcher behind it and his research was featured previously on LtU, mainly on row polymorphism in the Morrow Language.

So far there's no paper available on the language design, just the slides from a Lang.Next talk (which doesn't seem to have video available at Channel 9), but it's in the program for HOPE 2012.

We will be making this course, Brown's upper-level programming languages offering, available for free on the Web. People anywhere are welcome to view the lectures, read the materials, and do the assignments

This is a great opportunity! I have relied heavily on Shriram's lecture notes when I was starting out.

It is nice to see that he promises to give personal recognition for those who participate, and even has a system in place for giving partial credit to busy professionals who cannot spare the time to do all the assignments and projects.

My only misgiving is that the course uses Racket; I wish it was in Scheme.

Oleg provides various arguments against including call/cc as a language feature.

We argue against call/cc as a core language feature, as the distinguished control operation to implement natively relegating all others to libraries. The primitive call/cc is a bad abstraction -- in various meanings of `bad' shown below, -- and its capture of the continuation of the whole program is not practically useful. The only reward for the hard work to capture the whole continuation efficiently is more hard work to get around the capture of the whole continuation. Both the users and the implementors are better served with a set of well-chosen control primitives of various degrees of generality with well thought-out interactions.

As part of the ongoing design of the ParaSail programming language, we settled on a "pointer free" approach. Given that pointers (or references in Java parlance) are rather fundamental to almost all modern languages which allow the user definition of structures like trees, lists, sets, maps, graphs, etc., this seems like a risky decision. In fact, we have been very pleased with the result, and in some ways it requires only a slight shift from the familiar programming model, while in other ways it makes for a dramatic simplification in storage management, assignment semantics, analyzability, etc.

Coupled with a few other ParaSail rules, the elimination of pointers makes it as easy to parallelize ParaSail as it is to parallelize a pure side-effect-free functional language, while remaining very much in the familiar territory of the Java/C# class-and-interface-based object-oriented programming world. Overall, ParaSail is a pleasure to program in, and this is in no small part due to the elimination of pointers from the surface syntax and semantics of the language. Of course, pointers are likely to still be used behind the scenes by any ParaSail implementation, but that doesn't affect the simplicity provided at the programmer level of having banished them.

We have written a longer "blog" entry on this topic here:

http://parasail-programming-language.blogspot.com/2012/08/a-pointer-free-path-to-object-oriented.html

So, LtU is 12!! I don't think this should go unnoticed. But as I was mostly quiet around here this year I am not qualified to offer a state of the lambda retrospective. Feel free to do so in the comments and, as they say, have some '(cake).

The ECOOP 2012 best paper award this year was given to Bruno Oliveira and William Cook for the paper "Extensibility for the Masses: Practical Extensibility with Object Algebras".

This paper is (yet another) solution to the expression problem. The basic idea is that you create a family of objects via an Abstract Factory. You can add new objects to the family by extending the factory as per usual, but the twist is you can also add new operations by overriding the factory methods to do other things, like evaluation or pretty printing.

Bruno has also been collecting sample implementations using Object Algebras solving a simple expression problem example.

It appears that the Fortress project is wrapping up. I'd be interested in seeing more commentary of lessons learned.

The Xtext project has published seven little languages (call them DSLs or not) using a new API for JVM-based DSLs. They are examples and meant to help people understanding how to use the new approach. The basic idea is to allow reusing predefined general language constructs such as expressions and type references and use them at arbitrary places in your custom DSL.

The seven languages solve common problems :

• a simple scripting language
• a build language (similar to ANT or Gradle)
• a language to describe MongoDB documents
• something to wire up Guice modules
• a language for HTTP routing (similar to the one from play!)
• a template language for HTML docs
• a sweet little Logo-clone

The basic ideas and implementation steps for these languages are explained including code snippets and examples. Real world usages of this API are Xtend and Jnario.

IMHO, one of the main advantages of embedded/internal DSLs over external ones has always been the possibility to call out to the host language. You need things like expressions in most DSLs at some point. Therefore in external DSLs people often start to design half-baked expressions or even worst built the most common use cases into the language just to get stuck again half-an-hour later and add the next half-baked ‘feature’. Other folks hook in or modify generated code and extend it with the needed behavior.

I think these are main problems with external DSLs and that they are completely eliminated with the approach taken in Xtext for JVM languages. At the same time the good parts of external DSLs such as the syntactical freedom, special domain-specific validation and tool integration are still there of course.

We are very happy with the abstractions and are looking forward to feedback from language design experts.