On Tue, Nov 11, 2014 at 9:35 AM, Donn Cave
That could happen ... I suppose there's no one way to do it that fits every application, but often enough I can make do with the Haskell "CTYpe" record, and it gives me a Storable value that has a valid type enforced relationship to the C struct. You wouldn't always need or want a Haskell version of your C struct, per se, but if you do.
True, but... consider Bool, with no corresponding C type. Just picking something like CUChar is inconvenient and ugly on the haskell side.
Data.Vector.Storable is a new one on me! (I see it's in the non-portable, experimental category, so it figures.) The documentation I'm looking at seems to be saying it wouldn't be "instantiated" for Char, though?
It is actually, it's perfectly valid to have a vector of Chars. More importantly, you can have a vector of records that include Storable types. It's an acceptable use of Storable, I just think the "pun" where Storable for haskell types is the same as the Storable for C types is unfortunate. Anyway, in the big picture, I think hsc2hs is just too low level. We shouldn't be having to manually poke structs at all, and it's fundamentally dangerous even if you use all C types because there's no typechecking. Nothing will help you when someone updates the struct and forgets to update the Storable instance. If I were starting again (or advising someone who was starting from scratch), I'd try really hard to find something that directly generates marshalling code from the .h file, perhaps c2hs can do that.