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

[Don Stewart]

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