ANN: H98 FFI Addendum 1.0, Release Candidate 13

[Alastair Reid]

[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.