[Haskell-cafe] Re: Help from C libraries experts

[Maurício]

>>> Do you understand very well a C library and would like
>>> Haskell to have a binding for it?  (...)  If you are
>>> willing to help me with questions about your favorite C
>>> library, like compile options I should be carefull about
>>> or differences I may find between systems, I'll be glad to
>>> write a low level binding to it.

>> I think "bindings" is an unfortunate choice of name for
>> this package, as it doesn't tell us anything about what
>> it contains.  (...)

It's not important what it contains, but how.  Well, it does
contain bindings, as many as possible. The important thing is
that any new binding can be added following strictly the same
guidelines used for others. 'Bindings.Sqlite3' is just an
example on how this will be done.

Suppose that 5 people want to write 5 different USB high-level
modules. The beneficts are:

- they all can use the low-level binding in this package for
OpenUSB (which is not available now, until some expert on
that library helps me do it). No need for testing, debugging,
checking for portability or proper initialization, as all that
has been taken into account.

- no need to read documentation. Guidelines in 'bindings'
ensures that the documentation for the original package (in
this case, the C documentation for OpenUSB) is valid for Haskell
binding. If you know OpenUSB in C, you can use Bindings.OpenUSB
almost without even looking at the documentation for that module.

- if a bug is discovered in Bindings.OpenUSB, it's solved there.
Those 5 high-level modules won't need to check for the same
error.

- those writing the high-level modules have no need to learn
about 'foreign import'.

- if high-level coders fell unsafe about the behavior of the
API, they can write an HUnit test that will be added to the
test code in 'bindings'. (This is stated in the documentation.
If you write a test and it does apply, it will be added to the
test code.) All five high level modules benefict from that.

> For example, the StandardC module would seem to duplicate the
> 'cmath' > package: (...) While the Sqlite3 module duplicates:
> (...)sqlite

This package came from my need to use sqlite3. If 'sqlite'
existed before, it probably would not exist. But this is not
important.

What is important is: if 'sqlite', and all other many sqlite3
packages, removed their low-level ("foreign import .*" etc.)
and instead added 'bindings' as a dependency, they could all
count on "Many eyes make all bugs shallow" to the low level
code. And everybody could expend more time with the high level
stuff, which I'm sure everybody likes the most.

I would like this package to be a repository where we could find
any good portable C (and other languages, when FFI support that)
package. If that happens (and the maintainer will probably
have to be someone better than me) I think a new module space is
worthwhile. Maybe 'Foreign.Bindings.*' instead of 'Bindings.*'.

Sorry for the long post, but it took me a lot of time to get the
proper design for this package, specially for the guidelines.
If it doesn't work (i.e., nobody gets interested), it's dead
for good.

Best,
Maurício