Quoth Anthony Cowley
To support both kinds of users, we have designs like that used in the OpenGL library: a Foo-Raw library, with a friendlier API layered on top, perhaps in a separate package. If the "friendly" API turns out to be no friend of yours, you are free to turn to the raw wrappers.
Perhaps we should aim for a more systematic application of this design pattern? I know that I appreciate a more idiomatic Haskell API when it is available, and certainly do not want library authors discouraged from providing such a service solely due to the provenance of the functionality. On the other hand, when I am porting, say, C coded against a particular API to Haskell, being able to use a more symmetric API is beneficial.
I don't know the OpenGL example, but I gather you're talking about an API that's different in a practical way, not just a thin layer with the names spelled differently. In that case, assuming that it really is more Haskell-functional-etc, vive la difference! No one would argue with this, I think. I just think that's how far you should have gotten, before you need to think about new Haskell-style names. For examples where someone apparently felt that new names for everything was the first order of business, you could look just about anywhere in System.Posix. System.Posix.Terminal - at least the documentation helpfully reveals the actual POSIX 1003.1 function names, but try for example to figure out what has become of the the fairly commonly used "ICANON" flag, without looking at the source. If you're hoping that in the course of time a significantly functionally designed API will come along for any of these things, note that names it might have used are already taken. Donn Cave