Fergus Henderson wrote:
> > [...] 1. Mapping Haskell types to C types [...]
> This mapping assumes that you want the unboxed types in C.
Yes, C programmers are not that lazy. :-)
> What if you want to pass an unevaluated closure (e.g. so that you
> can later pass it back to Haskell and then evaluate it)?
This is what stable pointers are for and they are covered by the
mapping.
> What about Bool, lists, tuples, Array, Integer, Maybe, Either, ...?
It was agreed that only primitve types should be handled by the FFI
itself and that compound values are a case for a (un-)marshaling
library. We already have some ideas what this lib should look like
and some slightly differing modules for this exist, see e.g. C->HS,
the MPI binding or HOpenGL. Before a design for this is presented,
the low-level details should be finished.
Bool and Integer are a slightly different case: Boolean values *are*
primitive, but there is a plethora of representations on the C side,
differing in bit size, signedness, values... So IMHO it's better to
let the programmer explicitly write a one-liner for what the API in
question needs than to give a rather ad-hoc mapping. And it is not
clear to me at all what the representation of an Integer should be
on the C side. We can't tie everyone to e.g. GMP.
> Providing a C equivalent for Dynamic would help a bit; you could
> use that as a catch-all. But of course Dynamic itself is not yet
> part of standard Haskell.
Is there anything special to Dynamic that isn't covered by the above
mapping plus a higher-level marshaling library? I guess not, but that's
only a quick guess.
> Are there any requirements on what kinds of types the Haskell types
> map to? For example, is it OK for all these Haskell types to map to
> opaque struct types in C? If not, what exactly are the requirements?
The numeric types in Haskell should map to numeric C types (i.e. no
opaque structs), so C code like
HsInt16 i;
HsFloat f, g;
g = f + i;
works as expected. HsAddr should be a void* because Haskell's Addr
is not parameterized, so there is little room for being more specific.
HsStablePtr should be void*, too, for the reason mentioned in my
previous mail.
> What should happen with Int64 and Word64 if the C implementation
> does not support any 64-bit integer type? Or should conformance
> to the Haskell FFI specification require that the C implementation
> support a 64-bit integer type?
Good question. Has anybody a different idea apart from the above
conformance requirement?
> > 2. Mapping C types to Haskell types [...]
> What about `char *'?
> What about pointer types in general?
See item 3.
> > [...]
> > 2) ANSI C defines long double and some compilers have long longs,
> > but these special types are probably not worth the portability
> > trouble.
> ANSI/ISO C is pretty widespread these days; I think it would be worth
> including `long double'. The Ada 95 standard included
> `Interfaces.C.long_double', and that was 5 years ago. These days it's
> quite hard to find a pre-ANSI C compiler.
... unless you have HP-UX and didn't purchase the the optional ANSI
C compiler. >:-( Strange, HP-UX's normal cc understands long long,
but not long double?! Nevertheless, you're probably right and long
double should be included (CLDouble).
> > 3) Addr can be used for all kinds of C pointers.
> That approach compromises strong typing.
C compromises almost everything.
> It would be better to have a polymorphic Haskell type corresponding
> to C pointers.
We had a discussion about this topic some time ago and were reluctant
to add this without some previous experimentation. Perhaps some
Haskell systems will implement
data Ptr a -- opaque type
as an extension. BTW, Ptr is probably not fully polymorphic, e.g.
what should be the mapping for
Ptr (b -> [Maybe Int] -> IO (Integer, b))
?
> > 4) The following standard types are so ubiquitous that they
> > should probably be included, too: (any further types wanted?)
> [...]
> Here's a full list of the types defined by ANSI/ISO C (89)
> and POSIX.1:
Are there online-references for these standards? I only own
Harbison/Steele ("C - A reference manual"), and this is slowly
becoming a little bit dated.
> ANSI <setjmp.h> typedef jmp_buf
> [...]
> ANSI <time.h> typedef time_t
Hmmm, these are not only basic C types, but include some structs,
too. The FFI does not handle structs, so we can only use a subset
of the types listed above.
> POSIX <dirent.h> typedef DIR
> [...]
> POSIX <unistd.h> typedef ssize_t
Those should probably go into the Posix libs, not the basic FFI lib.
> > [...] 3. Byte order [...]
> Yes, there are more esoteric ones.
Could you give examples? I know that there are e.g. 4! = 24 ways to
arrange the bytes of a 32bit int, but...
> Furthermore it's generally a bad idea to write code that relies on
> byte ordering. I don't see any reason for the Haskell FFI to
> encourage this.
It's not a matter of encouragement, but a matter of necessity: There
are a lot of binary file formats out in the real world, and you really
need to know if some swapping is needed or not. But I agree that this
could go into module BinaryIO (discussed in a more or less private
thread).
Cheers,
Sven
--
Sven Panne Tel.: +49/89/2178-2235
LMU, Institut fuer Informatik FAX : +49/89/2178-2211
LFE Programmier- und Modellierungssprachen Oettingenstr. 67
mailto:[EMAIL PROTECTED] D-80538 Muenchen
http://www.informatik.uni-muenchen.de/~Sven.Panne
