Skip to main content

Haskell: Well-typed Programs Can't be Blamed

Last Wednesday, I went to a Bay Area Functional Programmers talk to see Philip Wadler give a talk on his paper Well-typed Programs Can't be Blamed.

Wadler was a good speaker. He was very friendly and interactive. He insisted on having people ask lots of questions. He called himself an "absent minded professor". Two things I didn't know about him were that he worked at Bell Labs and he also worked at Sun on Generic Java.

Having tried to cram technical papers into my head way too late at night, I was pleased to find out that he's pretty easy to understand in person. However, his slides weren't always bug free. There were a couple of errors in the equations. Apparently, academic papers can have bugs too ;)

The goal of the paper was to to mix typed and untyped modules in the same program. He admitted that untyped code lets you do fun and flexible things. His goal was to "coerce" a dynamic function to a typed function dynamically. This was done with a "contract", which is like a type declaration for a function that get applied dynamically.

I mentioned to him that Python 3000 had type annotations, and that Guido had envisioned that someone would come along and do type assertions in very much the same way contracts work. He admitted that people were using these techniques in the real world. In fact, the new version of JavaScript will have optional types. I forgot to bring up that Visual Basic had optional types years ago.

It's interesting to note that several people in the audience were interested in using Python and Haskell together in the same program. By the way, rather than calling Python an "untyped" language (which is clearly an insult to its dynamic nature), he called it a "unityped" language, because, basically, everything is an object.

A core theme of the paper was "the blame game": is it the function's fault, or the callers fault? Apparently, this is a normal part of talking about function semantics, but I had never heard it referred to as that before.

He extended his system to cover dynamic type systems (like Lisp), strict type systems (like Haskell), and super type systems (aka dependent type systems) all in the same program. A dependent type system lets you have types such as "int n where n > 15". Consider the ramifications of this. If you have two such numbers, and you subtract one from the other, you might end up with an int that doesn't match that constraint. Often, type constraints such as these must be enforced at runtime. What you end up with isn't so different from design by contract.

One interesting point he made is that the stronger your type system is, the braver you can be in relying on it. In a dynamic system, you might stick with simpler code because there's no compiler to catch your mistakes before running the code. This is an interesting counter-point to Bruce Eckel's argument that declaring your types in Java is a waste of time that prevents you from doing more useful work like writing unit tests. After all, you need to write unit tests anyway, since a type system can only catch a certain class of bugs.

Wadler admitted that even Haskell's type inferencer wasn't smart enough to figure out some of the things he wanted to do. He said that he felt himself sometimes wishing he could just tell the compiler to fall back to checking his types at runtime.

Someone in the audience was able to state that Wadler's conclusions applied equally well to languages that have assignment. His response was "Oh, that's too bad" ;) Apparently, that was a quote from some other computer scientist who was told that his research applied equally well to languages with a goto statement ;)

There was a point thirty minutes into the talk where some people started to get lost. However, there were a few people that understood everything he said and wanted more. I understood about 60% of what he wrote and 75% of what he said. I think that says a lot about how good a speaker he was.

His talk was very proof oriented. He thinks of himself as a mathematician. He brought up the fact that lambda calculus is isomorphic to proof reduction: "Programming isn't so arbitrary". This flew in the face of some of the things I've written, including Everything Your Professor Failed to Tell You About Functional Programming and Computer Science: What's Wrong with CS Research.

In thinking about interpreter design, I like to focus on what is useful, without regard to any similarities in the math world. (By the way, I am a mathematician too.) I have a feeling that computer science academics get too caught up in the math. Nonetheless, clearly, applying mathematical constraints can often be useful, and I found Wadler's point of view interesting.

Scala is a functional language, similar to Erlang, built for the JVM. Someone asked Wadler if he had looked at Scala yet. Clearly, Wadler has a functional bias ("It's what I prefer to work on."), and one big difference I discovered between Haskell and Scala is that Scala lets you interact with stateful Java libraries. After all, Java is very stateful. I could see how that would be a big turnoff for Wadler. Wadler's response was that clearly there's a need for state. A database of some kind is needed to hold long term state. He seemed happy with what Erlang had done with Mnesia. However, he felt that state was a "high level concept" and that it's better to keep low-level programming and concurrent programming stateless.

Agree or disagree, I definitely think Wadler's an interesting guy, and I'm glad I was able to go to his talk.


Anonymous said…
thx 4 the thoughts. guess one problem with java’s way of doing static typing is that it (to my understanding and in the absence of generics, which it now does have) never used to allow you to say simple things like ‘‘i want to have an iterable here’’, or ‘‘must be an iterable of numbers’’, or ‘‘must be an iterable of numbers between 0 and 12’’.

instead all you can do is assert ‘‘give me a class A object’’ which then accepts class B objects as well iff class B is derived from A.

add to that the restrictions of single inheritance (evil) and the braindead distinction between ‘‘integers as such and integers as objects’’ (evil evil) and you know why java code can be so endlessly tedious to conceive and write.

it is imho not so much static typing per se, it is java’s lack of expressivity when stating parameter constraints coupled with java’s oop implementation that makes things so hard.

python, on the other hand, has too few built-in type assertions, but it does allow you to do useful things. for example, to build one text from all the thingies in an iterable, you can can say eg ','.join( value for value in values ). this will fail if on of the values is not already a text, so you need an iterable of texts, which you can not succinctly express in that language. BUT it does work for general iterators of texts, for dictionaries with textual keys, for lists of strings, for tuples of strings and so on. to make up for the shortcoming, you’d have to write some type checking of your own, and that will never be as strict or reliable as in java (something that i can live with).
Mark said…
I know nothing about Haskell, is it a language as powerful thus intelligent as Lisp? Or is it close to C language (the language that is developed for UNIX system)?

I start programming with C++, but now my favoriate is C, I think C++ has so many features inside the language and it give the programmer too many choices, that may not be good. On the other hand I like the simplicity of C, last year I did a project with gstreamer, gstreamer is developed based on GOBJECT model (OO on C language). I have an impression on how easy to develop a gstreamer plugin with my C/C++ knowledge, even I know nothing about GOBJECT, I can complete the project easily. The architecture of gstreamer is well established by GOJBECT, so I think I would learn how to programming with GObject this year, to learn how gstreamer is established.
jjinux said…
Wolf, thanks for your comments.

> ‘‘i want to have an iterable here’’

That's what interfaces are for in Java.

> ‘‘must be an iterable of numbers’’

Yeah, that wasn't possible until generics.

> ‘‘must be an iterable of numbers between 0 and 12’’

That's probably still not possible without creating a new class that can only store such numbers.

> and the braindead distinction between ‘‘integers as such and integers as objects’’

I do like the fact that everything's an object in Ruby and Python.

> it is imho not so much static typing per se

I'm not against static typing, as long as you give me a language with an ML type system ;)

> python, on the other hand, has too few built-in type assertions

I'm going to have to disagree with you there ;)

> ','.join( value for value in values)

That's easier written ','.join(values)

> this will fail if on of the values is not already a text, so you need an iterable of texts, which you can not succinctly express in that language.

I beg to disagree: ','.join(map(str, values))

> that will never be as strict or reliable as in java (something that i can live with).

Python's type checking is just as reliable as Java's. It's just that it's done at runtime (using duck typing) rather than at compile time.
jjinux said…
> I know nothing about Haskell, is it a language as powerful thus intelligent as Lisp?

I always like to joke that Haskell makes Lisp look like an imperative language in comparison ;)

> Or is it close to C language (the language that is developed for UNIX system)?

It's nothing like C.

> I think C++ has so many features inside the language and it give the programmer too many choices, that may not be good.

I know what you mean.

I think gobject is definitely interesting. I first did OO C programming in GTK. I prefer C over C++ too.

Popular posts from this blog

Drawing Sierpinski's Triangle in Minecraft Using Python

In his keynote at PyCon, Eben Upton, the Executive Director of the Rasberry Pi Foundation, mentioned that not only has Minecraft been ported to the Rasberry Pi, but you can even control it with Python. Since four of my kids are avid Minecraft fans, I figured this might be a good time to teach them to program using Python. So I started yesterday with the goal of programming something cool for Minecraft and then showing it off at the San Francisco Python Meetup in the evening.

The first problem that I faced was that I didn't have a Rasberry Pi. You can't hack Minecraft by just installing the Minecraft client. Speaking of which, I didn't have the Minecraft client installed either ;) My kids always play it on their Nexus 7s. I found an open source Minecraft server called Bukkit that "provides the means to extend the popular Minecraft multiplayer server." Then I found a plugin called RaspberryJuice that implements a subset of the Minecraft Pi modding API for Bukkit s…

Apple: iPad and Emacs

Someone asked my boss's buddy Art Medlar if he was going to buy an iPad. He said, "I figure as soon as it runs Emacs, that will be the sign to buy." I think he was just trying to be funny, but his statement is actually fairly profound.

It's well known that submitting iPhone and iPad applications for sale on Apple's store is a huge pain--even if they're free and open source. Apple is acting as a gatekeeper for what is and isn't allowed on your device. I heard that Apple would never allow a scripting language to be installed on your iPad because it would allow end users to run code that they hadn't verified. (I don't have a reference for this, but if you do, please post it below.) Emacs is mostly written in Emacs Lisp. Per Apple's policy, I don't think it'll ever be possible to run Emacs on the iPad.

Emacs was written by Richard Stallman, and it practically defines the Free Software movement (in a manner of speaking at least). Stal…

JavaScript: Porting from react-css-modules to babel-plugin-react-css-modules (with Less)

I recently found a bug in react-css-modules that prevented me from upgrading react-mobx which prevented us from upgrading to React 16. Then, I found out that react-css-modules is "no longer actively maintained". Hence, whether I wanted to or not, I was kind of forced into moving from react-css-modules to babel-plugin-react-css-modules. Doing the port is mostly straightforward. Once I switched libraries, the rest of the port was basically:
Get ESLint to pass now that react-css-modules is no longer available.Get babel-plugin-react-css-modules working with Less.Get my Karma tests to at least build.Get the Karma tests to pass.Test things thoroughly.Fight off merge conflicts from the rest of engineering every 10 minutes ;) There were a few things that resulted in difficult code changes. That's what the rest of this blog post is about. I don't think you can fix all of these things ahead of time. Just read through them and keep them in mind as you follow the approach above.…