hsc2hs
hsc2hs copied to clipboard
haskell
Adding bytearray read/write/index constructs
This is an initial stab at resolving https://github.com/haskell/hsc2hs/issues/19. I'm not sure what I'm supposed to do in checkValidity though.
Consider this still a work in progress. This currently builds and works as expected, but I'm still exploring the design space.
I'm actually pretty satisfied with where this is now. I still need to add more documentation though. Would anyone mind reviewing this?
I've pushed some changes that add a changelog entry and add some of the functions to the readme. Additionally, I've added a large and fairly complete example to the readme showing how to use hsc2hs to help write a Storable instance and a Prim instance.
Open question: is #readByteArray really needed, or do we only need #readByteArrayHash. To write Prim instances, we only need the latter, but the former is nice to have in situations where I don't actually want to write out a full Prim instance.
@RyanGlScott Would you mind reviewing this? Some of the functions are currently not described in readme, but other than that, I think this is in good shape.
I'm wholly unqualified to give any sort of insights into how this code may be improved. But backing up a bit, I'm skeptical that these should live in hsc2hs in the first place, given that these macros don't appear to be usable outside of the specific context of the primitive library. Or am I misreading how these work? (I see references to indexByteArray and the like.)
Originally, I was content to let these live outside of hsc2hs. I rolled them up into a custom.h file and everything was good. But then in MR313, I started needing them in GHC itself, and when building GHC, only macros that support cross-compilation are allowed. So, custom.h cannot live there. In the aforementioned MR, I just copied the definition of the Prim typeclass into a GHC internal module so that the code generated by hsc2hs's macros would still work out.
What it comes down to is that hsc2hs needs to let users work on unpinned memory. It currently doesn't do this. The de-facto standard typeclass for working with pinned memory is the one from primitive. Maybe there's a way to avoid using a typeclass at all. I think this would involve writing the haskell type in the #readByteArrayHash call. (Something like #{readByteArrayHash struct pollfd, fd, Fd}.) Then hsc2hs could avoid relying on typeclass resolution and pick out the indexing primitive from GHC.Prim directly. I think this would work.
Not a maintainer, just leaving a comment to see if we can't move things along.
