Older blog entries for crhodes (starting at number 82)

SBCL Unicode work is progressing well. It's nearly at the stage where it becomes useful: it's already at the stage where we can do silly demos such as in this screenshot. Clearly, this isn't going to make it into sbcl 0.8.15; however, I have hopes that it will into 0.8.16 (or should that be 0.9.0 or even 0.1point0.pre1? We still have a little work to do before everybody's happy with supporting a 1.0 release: the issue isn't so much the stability of the code (which was engineered to last — parts of it are decades old!) as the desirability of supporting a suboptimal interface as stable; the main benefit from a developer's point of view of a pre-1.0 release is the ability to laugh away complaints about lack of backwards compatibility. Such days may soon be behind us.

We live in interesting times. SBCL has acquired a new web page layout (with some extra content, too!); Nathan has almost completed the 64-bit work which I dropped after submitting my thesis; Nikodemus, when he returns from studying hard, is likely to give us linkage tables (you can solve everything in Computer Science with an extra layer of indirection) and a single stepper; and I, along with some friendly helpers (and armed with four years of discussions on #lisp IRC), have started the slow process of making SBCL Unicode-aware.

With luck, people will use these exciting new features. It's sometimes hard to tell whether one is programming into a vacuum: I count myself lucky that I can work on SBCL projects for intellectual satisfaction, though I confess that I do prefer it when there is visible positive feedback from actual users...

Edinburgh was fun. Hard work, but fun. Singing with a nice bunch of people is always a good thing, and when we're doing such challenging masterworks as Tallis' Spem in alium (where everyone has to pull their weight: it's for eight choirs of five parts each...) it's good for the brain cells too: certainly better for them than the post-concert social occasions, aided and abetted by Scotland's sane licensing laws — unlike in England, alcohol may be served after 11:00pm.

Juho Snellman is a smart cookie.

SBCL is a large, complex beast: I've talked enough about how hard it is for a system to give the right answer, but when people start wanting it to give the right answer quickly, well... Juho Snellman has single-handedly found improvements to string hashing routines, to poor scaling behaviour with multiple threads, and now bignum division. It appears not to solve the performance problems that we're having with GSharp (which are probably algorithmic in nature: why are we doing arbitrary-precision calculations, anyway), but I should hope that some of the graphs in Andreas Fuchs' boinkmarks (once the nightly run has completed) will look interesting.

I've put up version one of proceedings of the lightning (5-minute in theory, closer to 10-minute in practice) talks from the Bordeaux Libre Software Meeting Lisp track. Not everyone made my arbitrary deadline, but most did: and for those who didn't, there is the possible lifeline of a version two at some point in the future. (I hope we'll get Gilbert Baumann's thoughts on reader/editor integration, and Tim Moore's on CLIM interoperability: it was interesting stuff).

Comments and corrections are welcome: either to the e-mail addresses listed therein, or on freenode's #lisp channel, where quite a lot of the authors hang out.

As for my “keynote” talk, which I'm conscious that I haven't discussed yet: essentially, I attempted to make the case for protocol-oriented programming.

“What is protocol-oriented programming?” the cry rang out. Well, it probably already has a technical meaning (I confess: I didn't check), but the way I mean it is as at least cursory thinking about whether it makes sense to document the means by which a program (or function, or basic computational unit) achieves something, as well as what it is intended to achieve.

Why would one want to do that? Well, in languages less impoverished than C and its cousins, it is possible to hook into provided functionality: Lisp in particular is very trusting, allowing the user (or, perhaps the author of library Y) to override behaviour in library X. A protocol is then the contract between these two libraries (and any overriding that has occurred) so that the resulting mixture continues to function as expected.

An obvious example of a protocol in this sense is the CLOS Metaobject Protocol: libraries or users are allowed to selectively override slot-value-using-class, but if it's overridden inconsistently with (setf slot-value-using-class), expect Bad Things to happen (so Don't Do That Then). However, I believe that there's much greater scope for protocol-oriented programming than has hitherto been realized: for instance, I bet the McCLIM people would love a protocol for fontconfig, rather than an opaque library. And so on, and so on.

Part of the point I was making was that the Lisp community is too small to build isolationist libraries, while undisciplined development (first, take a copy of the library; then, modify the source) leads to a scaling problem and a combinatorial explosion, making it difficult for any given user to use the enhancements by two other people. Of course, the downside is that protocol-oriented programming — or exposing your internals (see, it even sounds disgusting) — is difficult. Film at 11.

Bordeaux was fun. Let's do the amusing local colour things first, to suck you into reading about deeper, more meaningful stuff later.

Bordeaux has a waiting school (that's a school for waiters, obviously, not an institution that's anticipating some event). My visits to Bordeaux in the past have seen some of the products of this school; apparently, this time we met all the drop-outs. Star of the show was the gormless waiter at the pizza restaurant in the north of the city, who was incapable of taking the order (really! He had to get the chef out of the kitchen to take it), and ran out of supplies — these things happen; it is possible for restaurants not to have deliveries of things that not everyone wants, such as beer, but the limited supply of tomato sauce in a pizza restaurant is close to unforgivable.

The new tramway system is entertaining, too. Apparently rushed into production for political reasons, it's effectively undergoing live testing. When it works, it's relatively efficient; central Bordeaux to the ENSEIRB in about 25 minutes isn't too bad. For three of the eight journeys I took, that's more-or-less what happened, though in one of those three we did wait 30 minutes for the tram to arrive; the other five suffered breakdowns of some sort. Most amusing was the time we were warned that the line was down in two stops, and we would have to take a replacement shuttle bus; unfortunately, our tram broke down before we got there...

As for the conference itself. I was suitably impressed by the Smalltalk whizz-bang demos; it is nice to have pretty stuff on the screen. My talk (about protocol-oriented programming, on which more some other day, I think) was rather prosaic by comparison: just simple acclaim slides talking about various forms of extensibility, and why it might be a good thing. Much more interesting from my point of view were the lightning presentations: quick five-minute talks about things various people found interesting. Rudi Schlatte on simple-streams and Eric Marsden on serve-event were particularly entertaining, and Bruno Haible on case-preserving packages gives a different take on so-called modern mode lisp. I'm attempting to collect short summaries of these from the speakers to make proceedings available: stay tuned.

... and we're back! Inevitably, by the law of Professor Murphy, just as I'm about to leave for the Libre Software Meeting; also, by Parkinson's corollary, I've forgotten all the bloggable stuff that I could write here. Go look at this (scroll down to the end) for the executive summary.

One thing: I attended (and gave a paper [slides] at) the 1st European Lisp/Scheme Workshop in Oslo. That was fun; meeting new people, putting names to IRC nicks, and so on.

And now, I'm really looking forward to going to the hothouse of Lisp programming that is Bordeaux: as well as a good list of attendees, the locals (Robert Strandh, Tim Moore, Iban Hatchondo, Matthieu Villeneuve) should provide good conversation too. Particularly looking forward to the lightning presentations; less looking forward to finishing my talk...

À bientôt!

Something else that happened in the dark ages of the diary: I went to scheme-uk again. This should not be taken as indicative of any paradigm shift towards the Dark Side; however, a chance to hear Shriram Krishnamurthi speak is not to be sniffed at.

So what did he speak about? Shriram actually gave two talks: the second was probably more audience-pleasing (in that, well, it involved scheme: specifically DrScheme and FrTime), on the beginnings of functional GUI programming. Neat, but time will tell whether it's a practical advance on the current callback-based paradigm.

The first talk was, serendipitously, closely related to work I've been doing: Shriram presented results of examining the coverage of deltas (individual CVS checkins, say) by test suites, coming up with the mildly surprising result that the coverage is strongly bimodal: most changes affect either very few tests (one or two) or the whole suite.

This is similar in method and scope to work that I'll be presenting in Oslo at the Lisp/Scheme Workshop (side note: only €25 for attendance) on classifying benchmarks by examining the changes in timings caused by source deltas. Shriram's talk also leads naturally into repeating his analysis using pfdietz's test suite, with the added advantage that it's cross-implementation, and so not contaminated by a biassed worldview. On the other hand, the ANSI CL test suite isn't finished yet; this might cause a little difficulty in comparing results.

Still. Interesting stuff.

Long time no diary. Partly this was server troubles at advogato, and partly natural laziness and indolence. Does this augur good or ill for a forthcoming academic research career? We shall see.

What have we learnt in the meantime, anyway? Well, those who follow this diary may have observed a certain bias towards technical minutiae of Common Lisp and its ANSI specification. We have an amusing unintended consequence for your delectation this month: on a strict reading of the specification, it is not possible to portably define a constant equal to a floating point zero.

How did they manage that? Well, the ANSI committee might have sometimes overlooked things, but they weren't completely nuts. So it's a combination of a series of things, all but one reasonable.

• an implementation is free to evaluate DEFCONSTANT's value form at compile-time, run-time or both. This is reasonable, so that the compiler can do constant-folding.
• the consequences are undefined if DEFCONSTANT attempts to set an already-bound constant to a value that is not EQL to itself. In the vernacular, this means that it's OK to set a constant to a value that's the same as the one it's already got.
• the file compiler dumps objects according to an abstract similarity relationship, such that when the loader (linker, to you static language unwashed masses) gets involved the resulting object is similar to the one that was dumped. A reasonable specification, given that the loader can theoretically be from a different lisp session altogether.
• the TYPE-OF an object cannot involve the MEMBER type specifier. Reasonable, because otherwise (type-of <x>) is trivially `(member ,<x>), which doesn't tell anyone anything.
• similarity on numbers is defined as being of the same type and with the same mathematical value (under =).

Superficially, this last requirement looks reasonable, but there's a catch! 0.0 and -0.0 are necessarily of the same type, since the only type that can distinguish between them is a MEMBER type (or equivalently the EQL type); they are, in IEEE parlance, also representations of the same mathematical value; (= 0.0 -0.0) is true. Thus, technically, an implementation is free, on compiling and loading

(defconstant +foo+ -0.0)

to go as follows: firstly, evaluate the value form at compile-time, getting -0.0, and do the defconstant. +FOO+ now has the value -0.0. Then dump this code, and obeying the similarity rules, dump it such that the -0.0 is now 0.0. Now on loading, we attempt to set +FOO+, currently with value -0.0, to the value 0.0, which is not EQL to -0.0; hence we get undefined consequences. No, I don't plan to exploit this loophole in SBCL; we get enough complaints about defconstant as it is.

The moral of this tale? Maybe this.

In other news: no noticeable progress on the pi calculus, no.

Differential calculus, check. Integral calculus, check. Tensor calculus: well, at least the University of Cambridge believes I can do this adequately, so check. Lambda calculus is not a problem; though I haven't got the complete exposure to β-reduction and whatnot, I can fake it plausibly enough; check.

I'd vaguely heard of the pi calculus before; I had ignored it as being something Computer Sciency that was more-or-less completely irrelevant to practical programming. I can't honestly say that yesterday's joint uk-lispers/scheme-uk meeting (or the ensuing discussion at the pub) opened my eyes or changed my mind about it, but it might be worth a second read anyway.

The context? Dan gave a talk about SBCL's threading implementation, based on Operating System threads (and not userland implementations); we talked, among other things, about clone(); futexes and furwocks; locking and safety in data structures; signal handling (with particular reference to Linux on the SPARC — you don't want to know); and the default value of dynamic (“special”) variables in new threads.

The pi calculus bit relates, if I understood things correctly, to what primitives the implementation threading model should expose. There are probably cool theoretical results, but the impression I got yesterday was that no-one yet had a real-world implementation of anything interesting... the idea is that pi calculus gives you a set of ultraprimitives on top of which, given operating system support, one can build all the locking and synchronization operations one would like; the current situation is that we provide a set of primitives that are good for building some things and bad at others. Clearly I need to go away and read about things.