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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
