
On Tue, Oct 4, 2011 at 7:46 PM, Jason Dagit
On Tue, Oct 4, 2011 at 12:54 AM, Luis Cabellos
wrote: I understand your point. I didn't know the problems with cross module inlining that Haskell suffers. I learned the BSD3, I think is a good and I'll change it on github and I'll put in the next release.
Oh cool. Thanks! I think that's for the best. Someone sent me a link to this offline: https://github.com/judah/HsOpenCL
Maybe the two implementations can be merged into one super implementation :)
Thanks for the hint. It appears to be a good source (great source, far better than OpenCL), It's worth to follow it.
I see. My experience with the OpenGL bindings is that it can still be confusing for users of the library. The reason is simple, there are good docs for using the API from C and those docs tend to match the official specification. So people who are new to the Haskell bindings will need some documentation that explains how to go from the C API to the Haskell API. Otherwise users will need to read the source code directly to figure out where the function they need to call is located. Good haddocks help, but that's just one part of the solution. Being able to search for the function by name is also useful, so that's why I proposed adding something on to the end of the function name. So that people using search in their browser on the haddocks or using grep at the command line would find the function(s) they are looking for and (hopefully) minimize time spent searching.
It's a shame because, if we had dependent types we could encode the C API directly into Haskell.
I'll think about, i put it in the issue.
Thanks and I'll probably look at it some more this weekend. I have a test program I'm working on but I would need to port it to your bindings.
Thank again, :)
Also, if you use the #fun macro from c2hs to create the foreign imports you will need to use at least version 0.16.4 as previous versions do not honor stdcall.
Jason