Tue, 28 Mar 2000 20:37:24 +1000, Fergus Henderson <[EMAIL PROTECTED]> pisze:
> The ANSI/ISO C standard does not guarantee that `wchar_t' will be
> Unicode, or even that it will be large enough to hold Unicode.
> I believe that the Unicode consortium recommends against using
> `wchar_t' for Unicode if you want portable code.
It also does not guarantee that char is ASCII, nevertheless Haskell
assumes that it is. And allows int to be 128 bits, where Haskell does
not have such type. The Haskell FFI will not be portable to every
ANSI C anyway.
We should probably explicitly specify additional assumptions about
the C implementation.
It's probably not very important to what type Char maps to. It maps
to HsChar, which can be char or wchar_t or int or whatever, as they
are mostly compatible in C. It's easier to explicitly specify fewer
assumptions about exact correspondence of types, and provide conversion
functions instead (for Haskell) and rely on implicit conversions
between integral types (for C) - than to try to find whether Char
should be mapped to char or wchar_t.
OTOH CChar and CWChar could be any types which:
- map to C types which have the same physical layout as char and
wchar_t respectively,
- are convertible to Char using some given functions. These functions
will be used a lot, also other functions for integer types, so
maybe a shorter name than fromIntegral would be nicer.
So for example CChar could be Int8 and CWChar could be Int32,
provided that HsInt8 is signed char and HsInt32 is int, and signed
char is compatible with char, and int is compatible with wchar_t on
the given implementation.
We could be more strict and make CChar and CWChar some more distinct
types, not synonyms to other integral types, newtypes say, and
guarantee that they map to char and wchar_t exactly. It would not
give much to guarantee exact correspondence on the C side. It would
give only one thing if I understand it: foreign exported functions
using CChar etc. will have proper C sygnatures in the *_stub.h file.
Will have exactly predictable C types, and not some compatble types.
Which makes sense if somebody wants to use C function pointers
with them.
So the question is: must CChar, CInt, CLong etc. map (in foreign
exported C type signatures) exactly to char, int, long etc., or it's
enough that they point to some physically compatible types (which
work even with mismatched function signatues)?
The converse is obvious. HsInt must map to Int exactly etc., there
is no choice. The asymetry is because we specify types using Haskell
type signatures, not C type signatures.
--
__("< Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/ GCS/M d- s+:-- a23 C+++$ UL++>++++$ P+++ L++>++++$ E-
^^ W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK 5? X- R tv-- b+>++ DI D- G+ e>++++ h! r--%>++ y-
