[Haskell-cafe] coding style vs. foreign interfaces

[Donn Cave]

Quoth Anthony Cowley <acowley at seas.upenn.edu>,
...
> 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