Though thinking about functions/libraries in terms of their type signatures is, in itself, a pretty new concept to a lot of people.

I remember, about a week into my exposure to Ocaml, asking what a functor was. "It's a function from a module to a module."

My response was along the lines of, What? It turns out, though, that Ocaml functors are really cool and can provide some of the functionality of Haskell's type classes.

Even more useful: searching for functions/libraries with a unit test?

Kind of like Squeak Smalltalk's method finder http://wiki.squeak.org/squeak/1916

And a reimplementation in Ruby http://www.nobugs.org/developer/ruby/method_finder.html

> Being able to search for functions/libraries by type signatures is very, very useful.

I can't remember the last time that I wanted to find a function that took two ints and returned a function.

I can remember the last time I wanted a function that did a particular operation.

Haskell has algebraic data types, which are much more expressive than conventional types. You can see that from his example. Of course, the types don't define the functionality, but they narrow it down much more quickly than the ints of C and Java (similar to google ranking of search results).

Python documentation, in contrast, seems to downplay (read: hide) the return type! It's not helpful to me (maybe I'm doing it wrong, or just not used to it). For example: http://docs.python.org/library/httplib.html#httplib.HTTPConn...

Python tends to deemphasize types due to its reliance on ducktyping and type-inferencing. If you look in the documentation, they don't really care about the input types either. Would it be nicer to have more typing? IMHO, it really depends on the setuation. It would be nice to have multimethods but declerative statements like in C would be horrible.

For the Nth time, dynamic type-checking IS NOT TYPE-INFERENCE.

Please stop willfuly misusing nomenclature. Please.

Right. Sorry.

I thought that was the reason - but if I give the wrong types, it won't work. Often, I can infer the types myself, but why not just tell me? I think there are conventions, like "it's a string or a number unless stated otherwise", and these defaults work great. You just need a little faith in the library writer.

For example, xmlrpclib.ServerProxy takes an URI - is that a string or a special URI object? I guess it's most convenient if it's just a string, but if you had just constructed the URI by concatenating the separate parts, it's inefficient to immediately parse them apart - and so Java has URI objects. Maybe it's just that Python admits it's a scripting language, and uses machine cycles to serve you - instead of the other way round. That's a nice idea.

I completely agree, and I believe that this is something unique to Haskell+Hoogle+Hackage.

Indeed. Type signatures mean that the code is naturally self-documenting.

My stance on the static/dynamic controversy is that static typing becomes a win as the amount of time spent reading others' code increases. A single programmer is probably going to be more productive in Lisp than in ML. (I don't know enough about Haskell to speak for it.) On the other hand, if I were choosing a base language for a team of 10 people who would all be editing the same code, I'd most likely choose one that's statically typed. Static typing enforces interfaces and allows the compiler to detect a decent share of bugs as well as most code breaks.

> Indeed. Type signatures mean that the code is naturally self-documenting.

Really? Knowing that a function takes two ints and returns a function is documentation?

And to think that I spend my time worrying about what a function does.

(Note: I have only read a bunch about Haskell. I am by no means an expert)

In my hobby work with Python, I absolutely have no choice but to read the documentation for a function to know what it does. The dynamic typing necessitates that the function itself tells me nothing. Consider:

def get_console_type(console)

Does this function take a console object? The string name of the console? The IPAddress of it?

In my professional work with C# (well, in this case C), the type signature tells me quite a bit more information.

ConsoleType GetConsoleType(IXboxConsole*)

One step further: does GetConsoleType have any side effects? It shouldn't by naming convention. But it turns out it did. It updates a cache, which can have a major effect on some totally unrelated thing.

Haskell, being a pure language, has to declare the presence of side effects. I'd have know this right away, without having to look at any documentation (there isn't any!). Furthermore, what if the function wasn't actually called GetConsoleType. What if it was called GetXboxType?

I really wished I could have searched for "All functions that return ConsoleType"...

Polymorphic functions are naturally self-documenting. What you are describing is not polymorphic.

The paper "Theorems for free" describes this: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.38.9...

Here's an example... let's say a function has type

[a] -> [a]

Just by looking at that type, the function has a number of properties.

1. The set of items in the result list are a subset (non-proper) of the set of items in the input list

2. Membership in the result list cannot be determined by the values of the members in the input list... ONLY by position

So, some functions that fit this type and therefore fit these properties...

1. id

2. reverse

3. tail

Not all ML/Haskell functions are semantically transparent based on the type signature, but type signatures are really useful.

You might wonder what function you use to find the length of a list in ML. The function obviously has to exist, but there are a number of things it could be called (length? count? size?). At the toploop, you type "Module L = List" and you get the module's type signature. You see that a function called length exists with type signature 'a list -> int. You know that that's the function you're looking for.

Other functions' type signatures give a great indication of what the functions do. For example,

List.map : ('a -> 'b) -> 'a list -> 'b list List.filter : ('a -> bool) -> 'a list -> 'a list List.filter_map : ('a -> 'b option) -> 'a list -> 'b list

All of these do the most intuitive thing that a function with that type signature should do. Obviously, not all functions can indicate their semantics through their type signature. For example, you might have one called partition with the following signature:

partition : ('a -> bool) -> 'a list -> ('a list) * ('a list).

You don't know whether the "true" list appears first or second in the returned tuple, but you can easily check this at the toploop.

When you're reading other peoples' code, static typing can be a huge win. If the writer of the code used the type system properly, this cuts your read-work by 80%, even without any other documentation.