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.

Malbolge figured out?

Taken out of order:

From Ryan Kusnery's weird languages page:

The day that someone writes, in Malbolge, a program that simply copies its input to it's output, is the day my hair spontaneously turns green. It's the day that elephants are purple and camels fly, and a cow can fit through a needle's eye.


I've succeeded in writing a Malbolge program that copies its input to its output. Since some of it is non-printing, here it is uu-encoded...

In addition the page contains a proof of Turing Completeness (of a slight modification of the language), and suggestions on how it could be made harder.

The Underhanded C Contest

Inspired by Daniel Horn's Obfuscated V contest in the fall of 2004, we hereby announce an annual contest to write innocent-looking C code implementing malicious behavior. In many ways this is the exact opposite of the Obfuscated C Code Contest: in this contest you must write code that is as readable, clear, innocent and straightforward as possible, and yet it must fail to perform at its apparent function. To be more specific, it should do something subtly evil.

I wasn't aware of this contest. This concept sounds like fun, the idea being to write source code that easily passes visual inspection by other programmers.

The challenge for the first UCC is to write a simple program that performs some basic image-processing operation, for example smoothing or resampling, but manages to conceal a unique imperceptible fingerprint in each image it outputs.

XML feed