Month: September 2009

Scion provides a way for emacs to chat to ghc, giving you nice squiggly red lines under your errors in realtime.

I thought I’d found a string encoding problem in scion, but after taking a long route (tcpdump etc) it turns out that it’s just a poor default. Out of the box, scion will assume that scion server (and in turn, ghc) speaks latin1. However, you can just add this to your .emacs to make it speak utf8 instead:

(setq scion-net-coding-system 'utf-8-unix)

Now your lambdas can be λ’s and you still get pretty error messages in scion!

Not sure if I got very much out of the Haskell Symposium today. After three days of ICFP I think I’m just a bit overloaded. On the plus side, every single talk contained at least one interesting nugget, but overall there wasn’t anything which really excited me. It was nice to see more about how GHC works. And I was certainly interested to hear about Jean-Philippe Bernardy’s lazy parsers from Yi – I had worried that it would be quite easy to trip up and accidentally cause everything to be evaluated, and indeed it sounds like that’s probably true. Conal Elliott’s talk about FRP reminded me about my previous (non-FRP!) job writing various physics simulators .. having done it in an imperative and stateful fashion, I completely understand the appeal of a composable declarative approach!

One other thing I noticed today; I keep forgetting that each ~30 minute talk is actually a distillation of maybe a year’s worth of work. Therefore, everyone who talks appears to me to have a superhuman ability to recognize problems, generalize them and instantly apply complex idioms to form a solution! Given the breadth of material covered at the conference, it’s somewhat of a whirlwind. But, whilst I only understand some modest fraction of what I’ve seen, I am starting to get a better idea of what kind of stuff people are working on, and what kind of approaches people take. It also makes me more aware of what kind of things I find interesting (and conversely, not interesting!) and where I might better target my efforts in the future.

So, for me, the best bit of ICFP was a common theme which underpinned a few of the talks. It was the idea that you can use programming as a way to learn stuff, rather than just a way to produce programs to run. In other words, the primary outcome of your programming session is an “aha” moment in your head, and if you get a runnable program too then that’s a secondary benefit but not the main objective.

So I’m not talking about learning how to program better. I’m talking about using a programming language as a way of writing down ideas. The act of writing them down often clarifies your mind. But then, as you write down more stuff you might notice commonality – and programming languages often let you capture that commonality and express it quite cleanly. And, perhaps, the resulting version will be something you didn’t ever anticipate – perhaps letting you see that two seemingly unrelated areas were in fact just two facets of one common underlying idea.

This theme came out clearly during the talks by Dan Piponi (sigfpe) and Conal Elliott; I didn’t manage to follow everything they covered, but to me they were both examples of this kind of approach. Very sweet, and much more interesting than ‘programming for programmings sake’.

Day 2 opened with Benjamin Pierce summarizing his experiments in making heavy use of a proof assistant (Coq) during his CS class. Basic summary was “its hard work for the organizer, but the students appear to gain a better understanding”. More concretely, he’s shared the coursework so that other people (ie. me!) can use it without having to fly out to the University of Pennsylvania.

Next two talks were over my head; I’m always surprised that naming and binding cause so much headache for formal systems. I’ve seen De Bruijn indices used before, but they cause people to drown in unhelpful arithmetic and so people look for other ways. Anyhow, I know I know nothing about this (although Sam Lindley did give me a high level overview), so I will skip onwards.

“Finding race conditions in Erlang” was practical and interesting – trying to find internal race conditions in a service by concurrently calling its api methods in random order. Well, ‘random’ order wouldn’t be so helpful, since part of the work was to find minimal examples where the concurrent calls had behaved differently from if they’d been called serially. They use quickcheck to generate the call sequences (and benefit from its minimization features) but they had to hook the Erlang VM at various points so they could control the scheduler and get some modicum of repeatability during their runs.

“Partial memoization of concurrency and communication” was more interesting than the title suggested. Memoizing pure functions is pretty easy – you do the work once, and stash the answer in a cache keyed off the argument values. However, for side-effectful computations this doesn’t work, since getting the right answer out without performing the side effects just ain’t the same thing. So, the idea was to track the side effect (specifically, message sends/receives in CML) and attempt to re-enact those interactions in a kind of ‘replay mode’. If all the interactions could be carried out just like in the original run, great, you can return the final answer and you’re done. But if the replay fails part way through, you can resume the execution of the original code (a continuation) from that point and at least you saved some work.

Fifteen years and still learning: C-u C-\ TeX in emacs chooses the tex input system; if you then type \forall or \exists, it’ll insert the appropriate unicode codepoint. Sweet! It’s an input mode, not a major/minor mode. It has very nice tab completion too. Picked this up during a random ICFP conversation. 🙂

[update: fixed the key binding! ]