What are all of the things this function could possibly do to its arguments?
(a -> b -> c) -> b -> a -> c
(a -> b -> c) -> b -> a -> c
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.
A type signature of Seed -> String -> Hash is pretty enlightening!
1. Call the function 2. error 3. infinite recursion
Technically correct - there are infinite possible error messages.
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.
Dynamic types are sometimes called “tags” to distinguish the case in which this information _does_ exist at runtime.
How about calling the function derivative?
Sounds like you could have used real documentation.
How would you write this with no constraints on the types involved?
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.
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.
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.
For one.
Now tell me: are types the best documentation?
f :: (a -> b -> c) -> b -> a -> c
f (+) 1 2
"cookie"
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.