Type warnings

Here's something that occurred to me the other day: consider ( duck-typed languages like Python )

OK, so far so standard. Now, most duck-typed languages are dynamic, which means that we only try to determine if bar has a spoffle method at runtime, and die with an error message when it doesn't (possibly after trying some error recovery, e.g. by calling an AUTOLOAD method or similar). But it occurred to me that in simple cases (which is to say, the majority), we could work out most of this stuff statically. For each function definition, see what methods are called on its arguments. Recurse into functions called from that function. Now, each time a function is called, try to work out what methods the arguments will support, and see if that includes the interface required by the function. Issue an error if not. Thus we get the code reuse benefits of duck typing, and the correctness benefits of static checking. If the static checking is slowing down your development cycle too much, drop back to fully dynamic checking, and only run the static checks on your nightly builds or something.

This also cleared up something else I'd been vaguely wondering about. In his splendid Drunken Blog Rant Rich Programmer Food, Steve Yegge says

Another problem is that they believe any type "error", no matter how insignificant it might be to the operation of your personal program at this particular moment, should be treated as a news item worthy of the Wall Street Journal front page. Everyone should throw down their ploughshares and stop working until it's fixed. The concept of a type "warning" never enters the discussion.

I'd wondered at the time what a type warning would mean. When is a type error mild enough to only warrant a warning? Here's one idea: a type warning should be issued when it cannot be proved that an argument to a function implements the interface that function needs; a type error should be issued when it can be proved that it doesn't.

This all seemed very interesting, and struck me as potentially a fun and reasonably easy hacking project, at least to get something workable going. But if it's occurred to me, it has probably occurred to someone else, so I asked the Mythical Perfect Haskell Programmer if he was aware of any work that had been done on static duck-typed languages. "Oh yes," he said, "O'Caml's one." Buhuh? Really? Well, that's O'Caml moved a couple of rungs up my "cool languages to learn" stack...

Business plan 2

A Japanese-style coffin hotel, with really good soundproofing, somewhere central in Edinburgh during the Festival, open 24 hours a day, with beds rentable by the hour. Imagine: you're a performer, your show's just finished, leaving you physically and mentally drained, and it's only 10am/midday/3pm/5pm/11pm/1am/whenever. Later on, you've got shows to see and flyering to do, but right now you just need a lie-down and a quick nap. But (because it's the Festival, and accommodation is in short supply) it would take the best part of an hour to walk home, and by the time you got there you'd have to start walking back into town...

Better yet, a coffin hotel in a shipping container, that could be towed around the place to similar events and set up with minimal fuss. Back-of-the-envelope calculations suggest that you could fit 12 standard-size coffin beds into a 20ft shipping container (or 24 into a 40ft one): my years at boarding school suggest we could probably up the density a bit without too much trouble. Annoyingly, shipping containers are only 2.5m wide, so we'd have to take the whole side off to allow access rather than just running a corridor down it if we want the beds to be 2m long.

Ventilation and laundry would be problems, but someone somewhere has already solved those problems, I'm betting...