briqueabraque:
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.
Could you perhaps then summarise what design rules you're using? For example, why did you pick the new 'Bindings' namespace? What are you doing that's different to having standalone small packages? One risk I see is that 'bindings' will depend on a large number of C libraries -- i.e. if i just want to use cmath, I will also need sqlite3 on my machine for bindings to build. That seems problematic. Maybe this is a better discussion for libraries@? -- Don