Type warnings

[pozorvlak]

Here's something that occurred to me the other day: consider duck-typed languages like Python. The idea of duck typing is that if something walks like a duck, and quacks like a duck, then it might as well be a duck. Or rather, if something walks and quacks in a sufficiently ducklike manner, it doesn't really matter for your purposes whether it actually is a duck or not. Less metaphorically, we don't specify that the arguments to our functions can only accept (say) Integers, we only specify that they have to have an add() method. In fact, duck typing as commonly understood goes further: we don't explicitly specify a necessary interface at all, we specify it implicitly by the methods we call on our arguments.

An example is probably in order. Consider the Python code

def foo(bar, baz) :
    bar.spoffle()
    bar.buffy(baz.willow())
    baz.xander(bar.angel())

From that code, we can deduce that the first argument to foo must have methods called spoffle, buffy and angel, and the second argument must support methods called willow and xander. Now, here comes the clever bit. That's all that's necessary for foo to work. Supposing some clever hacker comes along later and invents a new datatype which it would make sense to foo, all they need to do to allow your code to work on theirs is to implement those methods in a sensible way. This can be done without any knowledge or forethought on your part. Maybe you honestly believe that fooing is something that can only be done to ScoobyGang objects, but in fact the algorithm is much more general, and will work with any TeenSuperHeroTeam. It doesn't matter: your code will still work. To achieve the same effect in Java or Haskell, you'd have to have defined a Fooable interface explicitly, and users of your library would have to start their code with a raft of

instance Fooable TheThem where ...
instance Fooable AquaTeenHungerForce where ...
instance Fooable PowerRangers where ...

type stuff. This is in fact how most of my Haskell code ends up looking: I find typing it almost physically painful. Until the RSI starts to kick in, at which point it becomes actually physically painful. And that's in the good case, where the author of the library I'm trying to use has thought about the kind of generalisation I want to make and defined the relevant interfaces.

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...

Comments

[johnckirk.livejournal.com]

VB.NET has some options for type warnings vs type errors, as described here:
http://msdn2.microsoft.com/en-us/library/3y20cc1z(VS.80).aspx

For instance, if I say something like:

Dim x as Integer = 0
MessageBox.Show(x)

then I'm doing implicit type conversion from Integer to String, so that can be a warning or an error depending on your preferences. (I use "Option Strict On", so it's an error for me.)

More generally, I think the key advantage of interfaces is for separate libraries, where you may not know the specific one until runtime. For instance, I've written n-tier applications which have a choice of data layers, so there's just one point in the code where I choose which DLL to load (e.g. SQL Server vs Oracle) and all the rest of my code refers to the interfaces rather than the specific classes. That means that the type checking is done at compile time.

There are also issues if I'm working on a library and I want to change some behaviour, e.g. by no longer supporting a particular method. With interfaces, I can say "I no longer implement IScoobyGang but I do implement IPowerRangers", then make whatever changes I like as long as I stick to those interface definitions. The calling code should check whether a given object implements a particular interface at runtime, and if not then it can handle that appropriately, rather than assuming that my code has a particular method and then crashing mid-function.

[pozorvlak.livejournal.com]

Not sure where to start with this. The whole point of duck typing is to enable the kind of code reuse you describe, without having to think about virtualising either the library or the calling code explicitly. With duck typing, you don't have to say "I no longer implement IScoobyGang but I do implement IPowerRangers" - remove the method, and it's done.

I understand the rationale behind explicit interfaces (you make a good point when you say "The calling code should check whether a given object implements a particular interface at runtime, and if not then it can handle that appropriately, rather than assuming that my code has a particular method and then crashing mid-function" - this can be done in dynamic languages, but it's a bit more of a faff), but for the kind of code I write, they're overkill. And I have a very low tolerance for writing unnecessary lines of code.