[Haskell-cafe] HDF5 binding

[James Cook]

On Mar 4, 2011, at 8:25 AM, Ferenc Wagner wrote:

> Hi,
>
> This is fairly extensive indeed!  I got nowhere near this, but also  
> took
> a somewhat different angle, especially by using StorableArrays for
> passing arrays around (I used HDF5 in conjunction with LaPack).  I  
> also
> experienced with going a little higher level here and there.   
> Attributes
> aren't implemented yet, because that would require making location  
> ids a
> type class.  An unsolved problem is the safe representation of  
> ranks: I
> went for generality by using lists for indexing, but it would be  
> nice to
> express dimensionality constraints in the types (with sane syntax).
> Maybe there's a handy technique for this, I didn't explore the field.
> Talking about indexing, choosing Fortran convention seems to be a
> mistake in retrospect, but that's no big deal.

I've skimmed through your code, it looks good.  It's definitely a bit  
higher level than mine - mine is (intentionally) little more than a  
bunch of types and foreign imports with names changed minimally,  
mostly just uppercasing or lowercasing the "H5?" prefixes as needed.   
That approach seems to work really well for large C interfaces (like  
OpenGLRaw, etc.) if for no other reason than that it exposes the C  
interface via Haskell's much-better type system and documentation  
tools.  I'll read through yours in more detail, it looks like there  
are some good ideas there that I can apply when I start working on  
something higher-level.

> I attach my code so you can get a better idea what I'm talking about,
> maybe you can find some usable pieces.  Separating the generic hid  
> type
> into specific newtypes worked out to some extent, but maybe isn't a  
> good
> idea at the lowest level (where the FFI makes it automatic).  I'd need
> broader experience with the HDF5 API to tell.

My experience isn't especially broad either, but from what I've seen a  
type-level approach for distinguishing hid_t usages ought to work, at  
least most of the time.  One thought I have is to use a phantom type  
parameter at the lowest level, so that foreign imports can either  
constrain it or not, as the situation seems to call for.

Thanks

-- James