On 28-Mar-2000, Manuel M. T. Chakravarty <[EMAIL PROTECTED]> wrote:
> Sven Panne <[EMAIL PROTECTED]> wrote,
> > 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, and char is what one wants most of the time, anyway.
>
> As already pointed out by others, I guess, this one will
> bite us one day. So maybe, we should say that `HsChar'
> corresponds to `wchar_t'
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.
> and use `CChar' on the Haskell-side
> whenever we want to guarantee that we use 8bit characters.
> > 3) Stable pointers are passed as addresses by the FFI, but this is only
> > because a void* is used as a generic container in most APIs, not because
> > they are real addresses. To make this special case clear, a separate C
> > type is used here. Foreign objects are a different matter: They are
> > passed as real addresses, so HsAddr is appropriate for them.
>
> Yes, but it is not enough to say that `HsStablePtr' is
> probably a `void *'. We have to guarantee that (I guess, we
> also have to guarantee it for `HsAddr'). If a system
> doesn't implement exactly this mapping, all bindings to C
> code using C-style polymorphism (see my favourite `glist.h'
> example from previous email re this topic) will break
> anyway.
If, as I suggested, `StablePtr Foo' maps to `struct HsStablePtrFoo *',
C-style polymorphism using `void *' will still work.
You just need `StablePtr t' where `t' is a type variable to
map to `void *'.
> > 4) The following standard types are so ubiquitous that they should probably
> > be included, too: (any further types wanted?)
> >
> > Haskell type | C type
> > -------------+---------------
> > CSize | size_t
> > CSSize | ssize_t
> > COff | off_t
> > CPtrdiff | ptrdiff_t
>
> Surely a good idea to include those, but as Fergus said,
> then it would be good to include as many of the ANSI C types
> as possible. Which ones can we do without running the risk
> that they are implemented as structs by some C system.
The following ANSI/ISO C 89 types are guaranteed to be integer types:
wchar_t
ptrdiff_t
size_t
sig_atomic_t
The following are guaranteed to be arithmetic types:
clock_t
time_t
Note that in C 99, the complex number types are arithmetic types, so it is
technically legal for a C 99 implementation to define e.g. clock_t as
`double _Complex'... but in practice that is unlikely (for backwards
compatibility with C 89, not to mention programmer sanity), so I think
we can ignore that possibility.
--
Fergus Henderson <[EMAIL PROTECTED]> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger [EMAIL PROTECTED] | -- the last words of T. S. Garp.
