Sven Panne <[EMAIL PROTECTED]> wrote,
> "Manuel M. T. Chakravarty" wrote:
> > [...] So, how about providing functions that advance the `mem'
> > pointer for you or even have `writeXXXOffAddr' return the
> > next address after the datum just written?
> > [...] This is, however, maybe not so helpful because of alignment
> > constraints that are harder to satisfy manually than in
> > generated code. [...]
>
> How about a new class subsuming the plethora of functions in Addr:
>
> class NoGoodIdeaForANameYet a where
> sizeOf :: a -> Int
> alignment :: a -> Int
> indexOffAddr :: Addr -> Int -> a
> readOffAddr :: Addr -> Int -> IO a
> writeOffAddr :: Addr -> Int -> a -> IO ()
>
> sizeOf returns the size of the corresponding C-type in bytes, alignment
> returns the alignment constraint for the given type and the underlying
> architecture, indexOffAddr/readOffAddr/writeOffAddr behave like the
> similarly named functions in Addr, but the second argument is a *byte*
> offset. The first two methods would make FFI stuff more portable
> without resorting to autoconf or other hacks.
I wouldn't call autoconf a hack :-) But I agree very much
with your class definition - in fact, I use a similar one in
the marshaling library of the C->Haskell tool,
http://www.score.is.tsukuba.ac.jp/~chak/haskell/c2hs/
where I call the class `Storable'. My class doesn't include
the alignment as this only is of moderate help to the
programmer, and mainly useful for a tool. Anyway, such a
class seems to be a nice way for expressing the information
about marshalable data types.
Cheers,
Manuel
