Hi, Do you understand very well a C library and would like Haskell to have a binding for it? I've been working on this package: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bindings My goal is to have a place where one can find reliable and comprehensive low-level bindings to foreign libraries, so that writing higher level bindings becomes an easier task. 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. Best, Maurício
briqueabraque:
Hi,
Do you understand very well a C library and would like Haskell to have a binding for it?
I've been working on this package:
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bindings
My goal is to have a place where one can find reliable and comprehensive low-level bindings to foreign libraries, so that writing higher level bindings becomes an easier task.
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. Looking at the code, I see: * Bindings o Bindings.Sqlite3 o Bindings.StandardC o Bindings.Utilities Which would traditionally be placed under, say, Database.Sqlite3 and perhaps: Foreign.C.Standard but they'd be in separate packages. Can you explain the rationale behind putting them in one large package, rather than separate packages? And is there a more explanatory name than "bindings"? -- Don
dons:
briqueabraque:
Hi,
Do you understand very well a C library and would like Haskell to have a binding for it?
I've been working on this package:
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bindings
My goal is to have a place where one can find reliable and comprehensive low-level bindings to foreign libraries, so that writing higher level bindings becomes an easier task.
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.
Looking at the code, I see:
* Bindings o Bindings.Sqlite3 o Bindings.StandardC o Bindings.Utilities
Which would traditionally be placed under, say,
Database.Sqlite3
and perhaps:
Foreign.C.Standard
but they'd be in separate packages.
For example, the StandardC module would seem to duplicate the 'cmath' package: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/cmath While the Sqlite3 module duplicates: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/sqlite -- Don
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
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
Do you understand very well a C library and would like Haskell to have a binding for it? (...)
Could you perhaps then summarise what design rules you're using?
Yes. They are summarised at the main module documentation: http://hackage.haskell.org/packages/archive/bindings/0.1/doc/html/Bindings.h...
For example, why did you pick the new 'Bindings' namespace?
The most important guideline is: users guide guidelines. If you have a better sugestion for a base module name, please open a ticket at development website, under 'Issues/Create new issue' (you can do it as anonymous): http://bitbucket.org/mauricio/bindings
What are you doing that's different to having standalone small packages?
I'm trying to write "canonical" bindings libraries.
One risk I see is that 'bindings' will depend on a large number of C libraries (...)
Sure. I would like to have: bindings-common bindings-testsAndExamples bindings-sqlite3 bindings-openusb bindings-agar etc. But I thought I should not polute hackage before this package get at least a few people understanding and agreeing with the concept.
Maybe this is a better discussion for libraries@?
OK. I'll repost there, with text updated after your thoughts. Thanks, Maurício
Maurício
bindings-agar
http://permalink.gmane.org/gmane.comp.lang.haskell.cafe/51478 -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited.
- 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.
Having OpenUSB bindings would be great - I just submitted a proposal for it on the proper reddit - but like Don, I don't see why having it in a bindings library is better than having it in a smaller package like "hsOpenUSB". If this is all about giving users some sort of quality assurance of the contained modules then perhaps a metapackage would be good or a haskell platform like project. Thomas
Hello Maurício, Wednesday, April 29, 2009, 11:09:04 PM, you wrote:
My goal is to have a place where one can find reliable and comprehensive low-level bindings to foreign libraries, so that writing higher level bindings becomes an easier task.
it looks impractical. better will be to provide each binding or group of related bindings as separate library -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
Hi, Maurício wrote:
My goal is to have a place where one can find reliable and comprehensive low-level bindings to foreign libraries, so that writing higher level bindings becomes an easier task.
Like others, I think you should consider making this place not a single package, but a bunch of packages. For example, one could make a convention that a package named bindings-foo contains low-level bindings to a c library foo. In your guidelines, you say:
Code should be portable and easy to build.
Does your understanding of "portable" include Windows? The problem with windows is that you usually do not have these c libraries installed, and no easy way to install them, so a binding is not enough. For example, the Haskell package zlib bundles the actual zlib c code for Windows users, which works not too bad. Do you plan to support this kind of thing in your bindings project? I am not sure which kind of c libraries can be reasonably included in cabal packages. I guess the idea breaks with more complicated build systems for the c library, and with libraries written in other languages then c, and with libraries which are supposed to be linked against dynamically, and with complicated license situations, and in all kinds of other situations. Anyway, if there are more such libraries then just zlib, maybe a naming convention would be helpful, like: - bundled-foo is a package which contains just the c code of foo - bindings-foo contains the low-level bindings for foo Now bindings-foo could use cabal configurations to depend on the c library directly on most systems, but depend on bundled-foo on Windows. This way, on all systems, you could just install bindings-foo and be able to use the library. If you have special needs, you could still use an explicit flag on Windows to configure bindings-foo not to depend on bundled-foo, and install the c library yourself instead. Tillmann
My goal is to have a place where one can find reliable and comprehensive low-level bindings to foreign libraries, so that writing higher level bindings becomes an easier task.
(...) In your guidelines, you say:
Code should be portable and easy to build.
Does your understanding of "portable" include Windows?
My thought on that was: anyone trying to wrap a library will have to solve this kind of problem. So, if it is possible to write such wrap, at least one solution exist, and 'bindings' set will try to select the best one for general use. Sometimes, this may be adding the C code itself, as is my current attempt on sqlite3. Sometimes the task can be delegated to pkg-config. Actually, that is the reason why my first post was a call for help from libraries experts. This has to be solved on a per library base. Thanks, Maurício
participants (6)
-
Achim Schneider -
Bulat Ziganshin -
Don Stewart -
Maurício -
Thomas DuBuisson -
Tillmann Rendel