Lambda the Ultimate

Hello All,
I recently happened upon the paper Prototypes with Multiple Dispatch by Salzman, and I decided to try implementing my own version of the PMD model he described in Scheme. As an extension to his model, I've added in support for CLOS style Method Combinations, such as the :after, :around, :before, and :standard dispatch orders.

Now, as near as I can tell, there haven't been any whitepapers written on the subject of combining PMD with Method Combinations, so I thought I'd ask you guys: Have you heard of anything like this? Even if you haven't, are there any pitfalls or oppertunties that you might be able to point out regarding this?

Thanks,
rhat

Edit: corrected ommision of the word "out".

In the Cat language I found it neccessary to have primitives which have embedded values. For example store#N would place the value on the top of the main stack into the Nth position in the auxiliary stack. There are currently a couple of other primitives like this.

Upon examination, this syntax yields a limitation: you can't use an expression in place of N. For example: store#1 + 2 doesn't really make sense. This lead me to consider the notation: store<1 2 +>. This isn't perfect, but it has a certain familiarity which I am comfortable with. This also extends relatively nicely to primitives like: local<int>, which pushes a new integer onto the auxiliary stack.

When I step back and look at this differently, I am embedding compile-time expressions between angled brackets (lt; and >). This makes the language specification more complex because the semantics for compile-time code are necessarily different from those of run-time code. This leads me to ask the question, shouldn't I allow compile-time or type expressions to be expressed using precisely the same syntax as the rest of the language? In other words why not place types on the stack, and if a type-expression can be resolved at compile-time, then let the compiler do so.

The only problem that I can see is that some expressions are not resolvable at compile-time, but this would simply lead to dynamic type expressions. I can see people potentially getting confused about what expressions can be evaluated at compile-time, and which ones are evaluated at run-time, but does it really matter?

It seems to me at this point that freely intermixing static and dynamic typing and evaluation is the right thing to do, but I'd like some feedback and other points of view.

Google's MapReduce Programming Model -- Revisited. Ralf Lämmel.

MapReduce is a programming model (and an associated implementation) used at Google for processing large amounts of input data (such as millions of documents) and generating keyed or indexed query results (such as the indexes used for Google's web search). The programming model is stunningly simple, and it allows the programmer to largely abstract from the parallel and distributed execution of the data-processing computations. Parallel execution is promoted by the assumed skeleton of MapReduce computations. Load balancing, network performance and fault tolerance are taken care of by the MapReduce implementation.

We revisit the MapReduce programming model in an attempt to provide a rigorous description of the model. We focus on the key abstraction for MapReduce computations; this abstraction is parameterized by the problem-specific ingredients for data extraction and reduction. We use Haskell as a lightweight specification language to capture the essence of MapReduce computations in a succinct, executable and strongly typed manner. Our study substantiates that clarity, generality and correctness of designs (or the presentations thereof) are easily improved, if modest functional programming skills are put to work.

This is a fun example of type-directed exploration and prototyping, and pokes some gentle fun of Google's (ab)use of standard terminology. It's neat to get a glimpse into the programming process of a very experienced Haskell programmer.

(From the forums.)