Enumerating the Rationals

Jeremy Gibbons, David Lester and Richard Bird (2004). Enumerating the Rationals. May 2004.

In this paper,we explain an elegant technique for enumerating the positive rationals without duplicates. Moreover, we show how to do so as a simple iteration, generating each element of the enumeration from the previous one alone,with constant cost per element (assuming unit cost for simple operations on arbitrary-precision rationals). Best of all, the resulting program is extremely simple...

Cute. Nothing earth shattering, but fun none the less.

The DSL, MDA, UML thing again...

Simon Johnston (IBM/Rational) on Domain Specific Languages and refinement:

My position is that the creation of domain specific languages that do not seamlessly support the ability to transform information along the refinement scale are not helpful to us. So, for example, a component designer that is a stand alone tool unconnected to the class designer that provides the next logical level of refinement (classes being used to construct components) is a pot hole in the road from concept to actual implementation. Now, this is not as I have said to indicate that domain specific languages are bad, just that many of us in this industry love to create new languages be they graphical, textual or conceptual. We have to beware of the tendency to build these disjoint languages that force the user to keep stopping and jumping across another gap.

I am not sure I want to go back to the argument between IBM and Microsoft about this stuff, but I think the notion of refinement is important from a linguistic point of view (e.g., embedding, language evolution, type systems, reasoning etc.)

But can refinement of the sort discussed here work in practice, or does it depend on language-design savvy architects? Maybe the difference between IBM and Microsoft is that the IBM approach assumes all modelling knowledge will come pre-packaged, being designed by modelling professionals and embedded in tools, where as the Microsoft approach assumes more design expertise from users?

Feel free to correct me, I am really unsure where all this is heading anyway...

Pragmatic Programmers Interview

Nothing really new for the LtU audience in this interview with the Pragmatic Programmers, but it is interesting to read their views on programming language. This quote is nice, even if you aren't a Lisp fan:

Ultimately, it comes down to ease of expression. If I can express myself in code at a level closer to the problem domain, then I'm going to be more effective, and my code is likely to be easier to maintain and extend. Paul Graham makes a big deal out of the way Lisp helped him while building the software that became Yahoo Stores, and he's right. These languages, applied properly, are a strategic advantage. I know some companies are using them with great success. And you know -- they're keeping quiet about it.

They also have an interesting take on the publishing industry, which certainly in academic circles is having a harder time justifying its existence.

Category Theory and Computer Science (CTCS'04)

The list of accepted papers and the abstracts of invited talks are now available.

Warning: This gathering is not for the faint of heart...


Progol isn't really a programming language, it's an Inductive Logic Programming system designed as an extension of Prolog.

A user manual and a technical paper are available.

Reading the paper requires some knowledge of machine learning. The user manual cum tutorial is much more accessible.

The orientation message

The orientation message was becoming annoying so I removed it from the top of the home page.

It can be found via the FAQ link on the left.

Mozart/Oz conference MOZ2004 - final CFP

I would like to remind you of MOZ 2004, the Mozart/Oz conference, whose submission deadline is coming up quickly (normally July 9, but due to several requests we will probably extend it by one week). The conference will be held on October 7-8 in Charleroi, Belgium. Highly recommended if you want to get the latest scoop on what is going on in the Mozart/Oz community. Many Mozart researchers and developers will attend too, and we expect lots of animated discussions. We'll also have two very interesting invited speakers, Gert Smolka and Mark Miller.

Another point that might interest people is that we've put a full set of lecture slides (more than 1000) on the CTM Web site (click on Supplements). The slides were made by Christian Schulte and Seif Haridi. The course is rather nontraditional. It might even be viewed as heretical in some quarters (we dare introduce concurrency before state, and we don't even mention inheritance). But we think it's a good way to start learning programming. The lecture slides only cover one third of the book, though, so if you want to see the other two thirds you'll have to get the book.

Whiteboard with Anders Hejlsberg

Link: MSDN TV: Whiteboard with Anders Hejlsberg

(The cameras seem to be following Anders around these days).

Anders answers questions from Tech-Ed audience about C# design decisions and possible future directions of the language. A number of subjects are discussed, including AOP, multiple inheritance, closures, guaranteed dispose, etc...

I'm about 30 minutes into the hour and a half video. Quite interesting from a PL perspective. I'll enter my notes into the comments section as time permits.

An Invitation to Ada 2005

A presentation about the additions and changes in Ada 2005.

It's interesting to see how Ada that once influenced C++, Java and eventually C# (e.g., generics, strong typing) is now being influenced by them (e.g., interfaces, container library, integration of tasking and inheritance).

As I've said here before, the Ada design process is quite interesting, seeing as most Ada users are quite conservative -- due to the fact thar they are building mission critical software -- while the language designers try to move the language forward without alienating its user base.

Debugging Functional Programs

An interesting thread on the Haskell mailing list.

I am not sure whether the most reasonable conclusion from this thread isn't to not choose lazy languages. I don't think it's simply a problem of lack of tools. Debugging lazy code is iherently problematic.