Lambda the Ultimate

Objective Caml release 3.08.0 is official and incorporates many improvements. A big thank-you to the OCaml team for this stable release. Those on the bleeding edge of post-3.08 CVS work can follow Xavier's advice.

(Link)

Vadim Nasardinov pointed out this article, which although pitched at an introductory level, provides a reasonably thorough overview of functional programming possibilities in Java. It focuses on the use of closures and higher-order functions, via Java's anonymous inner classes, and works its way up to "using closures to implement business rules" as one of its concrete examples.

Perhaps a little too introductory for LtU, but articles like this can be a useful starting point when talking to Java programmers who've had little or no previous exposure to FP, or who need some hints about useful ways to apply FP concepts in Java. Using anonymous inner classes to implement e.g. GUI event listeners in Java is common practice, but often, more advanced and useful possibilities are overlooked.

I know I should be able to find it on Google, but I can't: Who was it who said something like, "Programming languages should be designed primarily for humans to read and only secondarily for machines to execute."?

Ralf Hinze. Theoretical Pearl: Church numerals, twice! Journal of Functional Programming, 2004. To appear.

This pearl explains Church numerals, twice. The first explanation links Church numerals to Peano numerals via the well-known encoding of data types in the polymorphic LC. This view suggests that Church numerals are folds in disguise. The second explanation, which is more elaborate, but also more insightful, derives Church numerals from first principles, that is, from an algebraic specification of addition and multiplication. Additionally, we illustrate the use of the parametricity theorem by proving exponentiation as reverse application correct.

A simple concept is used to demonstrate several interesting and useful techniques.

Hi,

Can anyone point me to a survey paper for approaches to parallel computation?

Googling, I've found Models and Languages for Parallel Computation (Skillicorn and Talia) which is a pretty good example of what I'm looking for (from an initial skim through). However, that's from 1996 - I'm wondering if there's anything newer (or just complementary).

Thanks,
Andrew

A very pleasant 1996 interview with Donald Knuth by Jack Woehr of Dr. Dobb's Journal.

In the Explaining Monads thread, Luke Gorrie wrote:

If someone could next show what makes type systems so interesting in terms that I'll understand then I'll be well on my way into the modern functional programming world.. :-)

When you write code, even in the most dynamic language, you always know something about the types of the values you're operating on. You couldn't write useful code otherwise - if you doubt that, try coming up with some examples of operations you can perform on a value without knowing something about the type of that value.

Type systems provide a way to encode, manipulate, communicate and check this type knowledge. In an earlier thread, you mentioned that you write the types of functions in the comments. That's an informal type system! Why do you do use a type system? Because type systems are useful, important, and as a result, interesting.

The question didn't mention the word "static", but I'll raise it anyway. The type knowledge I'm talking about is necessarily mostly static - you know it when you're writing the program, and it's knowable when you're reading the program. Since we can't write useful code without it, it's also very important knowledge. That raises the question, if this important static knowledge is present in our programs, shouldn't we make it explicit somehow?

Further, if possible, since we exploit and depend on this knowledge on almost every line of code we write, shouldn't we check it for validity as early as we can, even while we're writing the programs (e.g. within an IDE), perhaps before it's possible to run unit tests on them? Given this ability, why wouldn't you take advantage of it?

Of course, the answer to that is that encoding a program so that its every term can have its type statically checked, introduces some constraints. But as I've argued before, the alternative of avoiding all static encoding of type information (other than in comments) is mostly a reflection of weaknesses in the state of the art.

There's been a raging battle on comp.lang.scheme for two months and 300+ posts about interpreters, denotational semantics and compositionality. I've skipped most of it, but this post from Will Clinger was instructive to me, particularly the part on full abstraction:

In other words, one of the most un-abstract semantics that could be imagined is fully abstract. Examples like this are part of the reason full abstraction is no longer regarded as a terribly useful concept.

It turns out that full abstraction is more easily achieved by making the operational semantics *less* abstract than by making the denotational semantics *more* abstract. Hence a fully abstract pair of semantics is likely to be *less* abstract than a pair of semantics that are *not* fully abstract.

For all those (like me) who didn't get the memo, I just found out that the seemingly defunct ll1-discuss mailing list has in fact found a new home at:

http://lists.csail.mit.edu/pipermail/ll-discuss/

(via Val Henson's weblog)

This paper (from HotOS IX) describes a software design approach which seems very close to the design techniques erlang tries to encourage.

I found this attempt at a buzzword free explanation of aspect oriented programming from Adrian Colyer's blog in the June archives of the ll-discuss maillist just posted. I think I finally have some idea what the aspect oriented hoohah is about, at least I was able to read the Introduction to AspectJ and make some sense of it for the first time. Maybe I'm just dense but until now I just didn't get it. This comment from Pascal Constanza in the ensuing thread shed a little more light on it at least for me coming from a functional perspective.