Sven Panne <[EMAIL PROTECTED]> wrote,
> GHC's Addr module is meant to be used in conjunction with the FFI (at
> least this is what the docs told me :-), but its plethora of similar
> functions is not very nice and some often needed functionality is
> missing. Attached is my proposed new version of Addr, being very
> similar to the things in the "Staying alive" thread.
[..]
> Alas, almost nobody mailed his/her wishes for a marshaling library, so
> this proposal is obviously biased towards HOpenGL's (and I think
> Manuel's) needs.
>
> Comments/suggestions?
Looks good :-)
Some bits & pieces:
> * After playing around with this module, I think that it is a
> Good Thing (tm) that ...OffAddr use element offsets and not byte
> offsets. It makes instance declarations of the following
> form much easier:
>
> instance Marshalable a => Marshalable (Foo a) where ...
Why? You have `sizeOf'.
> instance Marshalable Word8 where
> sizeOf = const 1
> alignment = sizeOf -- not sure about this
You should also get them from `./configure'. I guess that
would be possible by using a struct like
struct {char c; long int x:8};
or something like that in the C2HS_CHECK_ALIGNOF test.
(Haven't tried it yet, but looks plausible, doesn't it :-)
> -- Hmmm, Int is a little bit strange here, C uses size_t
> foreign import ccall "malloc" unsafe mallocAux :: Int -> IO Addr
How about letting our favourite Mega Hack(tm) - autoconf -
do the job?
C2HS_CHECK_SIZEOF(size_t,$SIZEOF_INT)
and then use a similar mechanism as C->HS's `configure.in'
to compute a Haskell type for it.
It might be nice to change the name of the library to
something different than `Addr'. Actually, I think, it
would anyway be important to make a GHC-independent
definition of the FFI (yes, I _really_ want to have it in
Haskell 2, or however it is called), which requires to make
clear, which additional libraries we need in the Haskell
standard (a point, which wasn't clear to me from reading the
FFI document). So how about calling this library `FFI'?
(Where exactly the `Int' and `Word' stuff should go remains
a matter for discussion.)
We should maybe found a `Standard Haskell FFI Task Force' or
so (yeah, yeah, I know, these Germans always want to
organise a club or other organisation where they can discuss
everything to death ;-) So, the plan could be to make a FFI
definition (including libraries, which is GHC-independent
and to get other systems implementers to also implement
it). Then, the Haskell 2 Committee shouldn't be able to
resist :-)
Cheers,
Manuel
