[As I was about to send this, it occured to me that maybe you had made a typo and meant to write 'peekByteOff' instead of 'peekElemOff'? This seems less dodgy since peekByteOff is more usually used to access elements of structs where different elements have different types.]
I think the report is right and the libraries should be fixed even if a lot of code has to be changed to make the two agree. With the report version: 1) Simple programming errors are readily caught. 2) Less type information needs to be written (obviously at the cost of not catching the type errors in (1).) That is, if you specify the type of the value being peeked, you can infer the type of the pointer and vice-versa. 3) If you want to do something funny, you have to explicitly cast the pointer to make it happen which alerts readers to the fact that you're doing something funny. To be honest, I can't think of many cases where I would want the types you propose. peekElemOff is basically for arrays where all elements have the same type - why would you want to treat them as having different types? -- Alastair Reid > Never say never... The signatures for peekElemOff and pokeElemOff in the > report are less general than the ones in fptools/libraries/base: > > peekElemOff :: Storable a => Ptr a -> Int -> IO a > > vs. > > peekElemOff :: Storable a => Ptr b -> Int -> IO a > > (same for pokeElemOff). The latter is more flexible and is more in line > with the signatures of plusPtr/minusPtr. Furthermore, changing such a basic > function would probably break quite a lot of code, so I propose to change > the report, not the libraries. _______________________________________________ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
