Types are incomplete documentation. They may or may not be sufficient depending on the context.

There are some really great things about types as documentation, though:

1) It's machine-checked, so it's probably not out of date or mistaken, which can be worse than no documentation.

2) The interaction with my code is checked, so if I misunderstood the compiler often has my back.

3) With inference, I can often ask for docs for code I just wrote.

None of this is to say that there aren't usually other forms of documentation that should be produced.

What are all of the things this function could possibly do to its arguments?

(a -> b -> c) -> b -> a -> c

What about String -> String-> String ?

Unless what you're doing is content-agnostic String manipulation (i.e. a function to concatenate arbitrary Strings), this type signature wouldn't make sense. And since there are only a small number of meaningful content-agnostic string manipulations, I've already got a solid guess that this is probably doing concatenation! It could also possibly be doing substitution, or a few other things, but not much before it becomes a gaping code flaw that the types in use are still 'String'. Concatenating a person's name with a country name doesn't make sense. Nor does searching for a street address in a month. A type signature like String -> String-> String should only show up down in the implementation details of helper functions, or on the signatures of content-agnostic library functions.

This could equally well be a function which takes a string and a seed and returns the hash.

The more concrete the type signatures become the less they become documenting.

A signature of a -> a defines the id function because the type is so generic. A function of String->String can do pretty much anything.

But that's exactly my point. Why would something that is a randomization seed have type "String"? Why would a hash have type "String"? Why not type Seed and type Hash?

A type signature of Seed -> String -> Hash is pretty enlightening!

Infinite.

3 things:

1. Call the function 2. error 3. infinite recursion

Technically correct - there are infinite possible error messages.

It's my understanding that we have to involve a function call as a fallback, as a function call is the only way we have of producing a value of type c in the general case.

But we could potentially have some list of exceptions.

So one valid implementation would be: If c is string we always return hello world elseif a, b and c are integers we add the two ints. Elseif a and b are the same type we call the function with the argument order swapped. And finally, if none of these are the case, we call call the function with the arguments.

In a type system like Haskell's, a function with that signature has to be unconditionally polymorphic in its variable types, so you can't have a list of exceptions.

If you do want to be able to list exceptions in Haskell, that's what Typeable gets you. But then the type signature is different.

Types don’t exist at runtime in the way you’re describing. It isn’t possible to express a program that asks what type a value has.

Dynamic types are sometimes called “tags” to distinguish the case in which this information _does_ exist at runtime.

You need to rethink your #1.

How about calling the function derivative?

Sounds like you could have used real documentation.

> How about calling the function derivative?

How would you write this with no constraints on the types involved?

I hope you're not suggesting that it's impossible to write this function without such constraints. If so, you should jettison your PL as fast as you can.

In any case this is precisely the trouble I believe the typer enthusiast get into. You can keep pulling this yarn, refining your types to match the world as it exists today; meanwhile the dynamic typers forgot about this function days ago and are eating your lunch in productivity.

> I hope you're not suggesting that it's impossible to write this function without such constraints.

To be concrete about it, that's exactly what I'm suggesting.

Please demonstrate, in any programming language, a derivative function that is parametrically polymorphic - that is, the same machine code will handle absolutely any type that's thrown at it - floating point, integral, string, function, map, set, graph, etc. I do not believe it's possible, unless you have some very different notion of derivative in mind. I would be delighted to learn it is possible, and mildly pleased to learn of a reasonable use of the phrase "derivative function" that's other than what I'm thinking and which makes sense of what you've written above.

Or... other people working in other languages you (obviously) don't understand have their own effective ways of working which you also don't understand.

It's a lesson that could be better understood by parts of the Haskell community, to be sure, but it's not always clear how useful a tool can be when you don't really know how to use it.

And here, you have repeatedly shown that you really don't know what you're talking about - take the opportunity to learn.

f(+’,1,2) = “cookie”

For one.

Now tell me: are types the best documentation?

Maybe I'm misunderstanding what you're saying, but how on Earth would a function

    f :: (a -> b -> c) -> b -> a -> c

result in

    f (+) 1 2

evaluating to

    "cookie"

? For one, the types (obviously, to me at least) don't work out.

Sounds like you could use some real documentation.

The types tell me that that's not the function in question. Type variables in Haskell mean the caller of the function gets to pick the types. That means the implementation doesn't get to - and the compiler makes sure of it.

You're pattern matching on a number and returning a string. The function might be handed a function and expected to return a file handle for all you know from inside the function.

a, b, and c are generic types. You need to supply an implementation of f that doesn't know anything about a, b, or c. How many such implementations are there? Can you supply at least two, both of which finish running in a finite amount of time and neither of which produces any error?