Mon, 27 Mar 2000 16:15:45 +0200, Sven Panne <[EMAIL PROTECTED]>
pisze:
> The time has come for another "final" :-} word on the low-level API for
> Haskell's foreign function interface.
What about the high-level API (apart from C2HS)?
> To solve this problem, every Haskell implementation should come
> with a header file FFI.h, which describes this mapping and the
> corresponding limits.
IMHO this name could be more specific, even if there is a little
chance that another language / library will want to use that name.
HsFFI.h, HaskellFFI.h or something.
> 1) Although the Haskell 98 report states that Char should be a
> Unicode character, a plain char is used here. No implementation
> uses Unicode so far,
Apart from HBC I've heard. What a pity. I will have to use newtyped
Ints in two projects (GHC). Patterns using character codes are ugly.
> and char is what one wants most of the time, anyway.
Now, surely. What when we finally implement Unicode?
I imagine that most I/O etc. will treat characters from outside world
as ISO-8859-1 by default (attaching per-handle filters will be the
next thing). That way anyone could use any encoding by converting
to and from the "nonsensical" encoding where Unicode values 0..255
represent characters from the desired charset, so they appear right
outside. IMHO it's simpler that adding another type representing 8bit
characters, and programs that don't care about encoding of data they
transparently read and write will work without modifications.
And BTW, please make Char 32bit, not 16bit. There are enough
problems now, with switching from 8bit. ISO-10646 specifies 31
bits and the U+0000-U+FFFF area is almost full. wchar_t has 32 bits
under Linux. "Fortunately" there is enough overhead of Chars being
full-featured Haskell objects that it should not create efficiency
problems. Is making Chars wide that hard, apart from FFI issues?
Back to FFI. So, when we finally support Unicode, and have wide Chars
and no plain Chars - how to distinguish char and wchar_t on the Haskell
side, as the Haskell type signature must determine the C type? I'm
sure that HsChar will be still char, and conversely Char will be equal
to CChar (with ISO-8859-1 mapping). So there is a question of CWChar,
a Haskell mirror of C's wchar_t.
One possibility is a newtyped Char. Ugly but working. Or an abstract
type with conversions provided. Hmm...
> 2) ANSI C defines long double and some compilers have long longs, but these
> special types are probably not worth the portability trouble.
long long is now ISO C (I'm not sure about how the newest C standard
is related to ISO and ANSI).
> 3) Addr can be used for all kinds of C pointers. Although in theory
> the length of a pointer could depend on the type of data pointed
> to, this is hardly a problem in practice.
I'm worried about function pointers. Will they really look the same
as data pointers in all platforms we will support? They certainly
did not in 16bit DOS.
Is it worth to formalize that Hs{Int,Word}{8,16,32,64} and ISO C's
{,u}int{8,16,32,64}_t are compatible or something?
> data ByteOrder = SmallEndian | BigEndian -- are there more esoteric ones?
> byteOrder :: ByteOrder
AFAIK it's called LittleEndian rather than SmallEndian.
--
__("< 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-
