I'm on the program committee for CUFP this year, so I'm a bit biased, but I feel very good about this year's program. For the first time, CUFP will be broken up into three parts:

• CUFP Tutorials on Friday October 1st. This is really the descendent of last year's DEFUN workshop. The tutorials were picked carefully, both for the interest of the topic and the quality of the teacher.
• CUFP Talks on Saturday October 2nd. Having been involved for a few years now, I really think it's an unusually strong group of talks. I would be pretty happy if we had a schedule populated with the best of the talks that we rejected, much less the ones that we ended up accepting.
• CUFP BOFs on the evenings of Thursday and Friday (Sep 30th and Oct 1). I'm really looking forward to these. These BOFs are still being organized, so you should follow the link and see if you have ideas to contribute. The BOFs should hopefully attract people from outside the usual CUFP audience, and we're hoping it will be a good way for FP developers to get together, talk about issues important to the various and sundry FP communities, and really get some work done.

A while back I mentioned that I'd given a guest lecture at classes at Harvard and Northeastern, and that the Harvard class had been taped. I finally got and uploaded that video:

You can click here for a higher resolution version. Sadly, the code samples are in spots a little hard to see here. If there's enough interest, I'll post the code samples here.

GADTs allow one to statically enforce stronger program invariants than are otherwise possible in a Hindley-Milner style type system. This post retells the story of how to "roll your own" GADTs using an explicit type of equality constraints. More interestingly, we discuss a particularly versatile definition of type equality in Haskell that can now be transcribed into OCaml due to the recent addition of first class modules.

There is a common perception that you should choose your type system based on the scale of your project. If you're writing a little program (i.e., a script), you should use a dynamically typed language like Python or Ruby. If you're building a large complicated piece of software, you're better off with a statically typed language like Java or (for the adventurous) OCaml.

I've always suspected that this is wrong; that static types improve your life even when writing small programs, although the advantage is clearly smaller. At least, this should be true for statically typed languages like OCaml and Haskell whose syntactic overhead is fairly low.

The beta version of Ocaml 3.12 has a couple of new features that relate to a post Stephen wrote a while back on how to ensure that a function definition is polymorphic. In this follow up post I will describe how one of those new mechanisms is essentially what you want for this purpose and the other is perhaps not due to a subtle interaction with how recursive definitions are type-checked.

Null is a pervasive concept in computing. Virtually all programming languages have a way of expressing nothing, nullity, no answer. But handling nulls correctly turns out to be tricky, and many of the contexts in which you find nulls, you'll also find confusing and error-prone semantics surrounding them.

The heart of the problem is that, in an attempt to make programming with null easier, nulls are often propagated implicitly through computations, allowing the programmer to write code that deals with nulls without explicitly contemplating how nulls should be dealt with.

My experience has been that this is a mistake; that if you want robust, easy-to-reason-about code, the programmer must think explicitly about how to handle null cases, and that programming languages would do well to provide programmers with good support for the requisite case analysis

The point can be illustrated by considering some of the contexts in which null arises.

Early in '09, I put up a post asking Private type abbreviations, what are they good for?. I got a lot of good answers to that question, but I thought I would mention one more: using private types for encoding subtyping relationships in phantom types.

CUFP is a yearly workshop for commercial users of functional programming. CUFP is aimed not just at industrial uses, but really at any uses of functional programming that are aimed at solving some pragmatic problem.

The workshop is co-located with ICFP, which is in Baltimore this year, and the scope of the workshop is bigger than usual. It spans two days rather than one, and in additional to the traditional talks, we will include a collection of invited tutorials and some Birds-of-a-Feather sessions as part of the schedule.

A couple of weeks ago I visited Northeastern and Harvard where I gave guest lectures on the subject of programming effectively in ML. In both cases, I was talking to a class full of undergraduates who had been studying ML for the semester. It was great fun, and in the Harvard case, the lecture was taped, so I hope to eventually be able to post a link to it here.

The lecture I gave was in part inspired by a book I read years ago called Effective Java, by Josh Bloch.

I'm pleased to announce that we now have ocamldoc generated documentation available for Type-conv, Bin-prot, Sexplib, and Core. You can find them here:

http://www.janestreet.com/ocaml/janestreet-ocamldocs/

The module paths in the documentation for Core and Core_extended are relative to Core.Std and Core_extended.Std

You can also find a tarball here:

http://www.janestreet.com/ocaml/janestreet-ocamldocs-2009-11-11.tgz