Top N Papers 2005

2005 is nearly over, and as everyone knows, December is the time for compiling hugely subjective Top 5 (10, 20, 100) lists for everything under the sun. I think it would be fun to see everybody's favorite papers... Here's mine, totally off the top of my head (I'm sure I'm forgetting something essential):

(Don't worry about trying to post the "best" papers in some objective sense, just whatever excited you... Show me what I missed this year!)

Code Reading

LtU readers know that I am long time advocate of code reading. As I've argued here in the past, reading great code is the best way to acquire good programming skills. It's also a pleasure to read good code. Yes - reading code can be fun.

It turns out that I am not alone (though my conception of a code reading workshop is perhaps somewhat different than the things discussed there).

Anyway, this is a chance to continue one of my pet memes. Many of the pieces of great code I've read over the years come from language processing tools (e.g., compilers, meta-programming systems etc.) I don't think this is a coincidence.

Now's your chance to tell us your favorite examples.

The rules: The code must be beautiful and it must be programming language related (and no, being written in a programming language isn't enough).

Monads in Ruby

Monads in Ruby, a several-part work in progress, is an attempt to explain and demonstrate monads in Ruby. It looks pretty good so far, although I feel like we could coax a friendlier syntax out of Ruby with a little effort. Maybe in Part 4!

Obligatory LtU connection: the author credits Dave Herman's Schemer's Introduction to Monads as an inspiration.

(One of my co-workers mentioned this to me. I think he might have been making fun of me...)

The Reasoned Schemer

Guess what I stumbled across at my local bookstore?

Previously mentioned on LtU, and now available... When the book was announced, Ehud said:

Authored by two of my favorites, Dan Friedman and Oleg, I have such high expectations, that however great the book is going to be, I am sure to be disappointed...

After working through the first five chapters (and sneaking a look at the implementation at the end), I'm pleased to announce that no one is likely to be disappointed... It's a real tour de force.

As expected, the focus this time is logic programming, in the form of a new set of primitives elegantly implemented around a backtracking monad in Scheme. Of course the format is familiar and comfortable, and of course it's charmingly illustrated by Duane Bibby.

So, get your copy today, and congratulations to the authors on a job well done!

Multigame A Very High Level Language for Describing Board Games

Multigame - A Very High Level Language for Describing Board Games, John W. Romein, Henri E. Bal, Dick Grune. First Annual ASCI Conference, 1995.

Languages with implicit parallelism are easier to program in than those with explicit parallelism, but finding and efficiently exploiting parallelism in general-purpose programming languages by parallelizing compilers is hard. A compiler for a Very High Level Language, designed for a specific application domain, has more knowledge about its application domain and may use this knowledge to generate efficient parallel code without requiring the programmer to deal with explicit parallelism. To investigate this idea, we designed Multigame, a Very High Level Language for describing board games. A Multigame program is a formal description of the rules of a game, from which the Multigame compiler automatically generates a parallel game playing program.

An amusing DSL, and an interesting investigation of implicit parallelism.

Also see this later paper.

It would be nice to find a downloadable implementation, by the way.

Zipper-based file server/OS

We present a file server/OS where threading and exceptions are all realized via delimited continuations. We use zipper to navigate within any term. If the term in question is a finite map whose keys are strings and values are either strings or other finite maps, the zipper-based file system looks almost the same as the Unix file system. Unlike the latter, however, we offer: transactional semantics; undo of any file and directory operation; snapshots; statically guaranteed the strongest, repeatable read, isolation mode for clients; built-in traversal facility; and just the right behavior for cyclic directory references.

We can easily change our file server to support NFS or 9P or other distributed file system protocol. We can traverse richer terms than mere finite maps with string keys. In particular, we can use lambda-terms as our file system: one can cd into a lambda-term in bash.

The implementation of ZFS has no unsafe operations, no GHC let alone Unix threads, and no concurrency problems. Our threads cannot even do IO and cannot mutate any global state --- and the type system sees to it. We thus demonstrate how delimited continuations let us statically isolate effects even if the whole program eventually runs in an IO monad.

zfs-talk: Expanded talk with the demo. It was originally presented as an extra demo at the Haskell Workshop 2005

ZFS.tar.gz: The complete source code, with comments. It was tested with GHC 6.4 on FreeBSD and Linux

From: Zipper-based file server/OS

Neat, a referentially transparent filesystem with transactional semantics in 540 lines of Haskell. I can think of some interesting uses for this.


Ning is a new free online service for building and using social applications.

The apps are built using PHP and a simple XML-vocabulary based DSL called XNHTML.

As I've been saying for a long time here and elsewhere, it's all about programmability these days, and as the Ning folks realise DSLs are a very good technique for achieving end-user programmability.

Seems to me they could have gone the extra mile, and eliminated the need for PHP altogether, but I guess that would be asking for too much...

ICFP Programming Contest 2005 Results

Hooray for the winners and judges!!

Dynamic typing in OCaml

On many occasions on this site we've discussed embedding a dynamic type checking scheme in a statically typed language using a Univ type. On many of these occasions, it's been suggested that this is an in-principle solution that would never be usable in practice, Turing tar-pit, etc., etc. Well, someone decided to put their money where our mouths are, and now we have Dynaml.

I've only briefly looked at the tutorial, but this definitely goes a long way toward demonstrating a plausible Univ embedding of a dynamic type system. Of course, I'd be curious to hear what everyone else thinks...

(from the caml weekly news...) - CODeDOC 2002

CODeDOC 2002 was a collection of 'software art' projects. One work, W. Bradford Paley's [requires Java support in browser], is particularly interesting because it shows three different ways in which code is "read". The first, and simplest, is a linear scan through the source (the amber highlighting). Second is the sequence in which code was written (white). Third is the execution flow as the program executes.

It's striking how unrelated these three sequences are. Since temporal sequencing lies at the heart of programming, this struck me as worrying. But then, how should they be related? How should the program's structure and creation be related to its temporal flow? And, of course, how does this relate to the language chosen?

For example: if the code were purely declarative then why would there be any correlation between execution and layout? Is my intuition about the importance of any simple relationship between these flows misguided?

Anyway, it is certainly pretty.

XML feed