Fergus Henderson <[EMAIL PROTECTED]> wrote,
> 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.
Ok, what should it map to, then? (I don't know much about Unicode.)
> > > 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 *'.
Fair enough. In fact, I was not arguing against your
proposal, but wanted to point out that a recommendation
(``...is probably'') isn't sufficient in this case.
> > > 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
Ok, so, then how about including just these. Sven?
Manuel
