Sven Panne <[EMAIL PROTECTED]> wrote,
> Regarding 1. Mapping Haskell types to C types:
> ===========================================================================
>
> 2) It should be *guaranteed* that HsStablePtr and HsAddr are mapped to
> void* for the reason mentioned by Manuel. Nevertheless, these types are
> not useless, they serve as documentation what the pointer should mean.
In fact, as Fergus just convinced me, it is sufficient to
guarantee that they are either defined to be `T *' for any
`T'. ANSI C guarantees that any pointer can be converted to
`void *' and back without loss of information (K&R Appendix
A6.8).
This opens the possibility to suggest (or at least tolerate)
the trick of using incomplete structs for generating unique
type names in C land. This appears to be a promising method
to get some more consistency checking from the C compiler,
and so I think, we should not rule this technique out.
> 3) If ISO C has long long (don't know, my copy of Harbison/Steele doesn't
> mention it), Int64/Word64 should be made mandatory.
IMHO, let's forget about ISO for the moment. If we have a
clean proposal conforming to ANSI C, we can start a second
round - if we are really keen - and take on the ISO stuff.
But one thing after the other.
> 5) Let's explicitly state that Hs{Int,Word}{8,16,32,64} and ISO C's
> {,u}int{8,16,32,64}_t are the same. Having the HsFoo names around is
> nevertheless handy because it is not clear to me what #include one can
> use in a portable way (e.g. there is no stdint.h on HP-UX 10.20).
Yep, let's define our own names. #define's are cheap :-)
(Ok, typedefs if you insist...)
> 6) Add HsBool with a mapping to an arbitrary integral C type, see Fergus'
> point about a Haskell API. (Should we guarantee that False maps to 0 and
> True to something <>0?)
We don't make any guarantees for the mapping of Haskell
_values_ to C _values_ for any other type. Why for Bool?
In the spirit of the limits for numerals, we could provide
`HsFalse' and `HsTrue'.
> Regarding 2. Mapping C types to Haskell types:
> ===========================================================================
>
> 1) Add the following type synonyms to module FFI (if there is no
> corresponding Haskell type, the implementation should use the "closest"
> one):
>
> Haskell type | C type
> -------------+-------------------
> CLLong | long long
> CULLong | unsigned long long
> CLDouble | long double
Closest? And do what if a marshalled value does not fit?
Core dump? Or print an error message, ``Hohoho, you fool
thought you can write a portable binding???''
We could have compliant and weakly compliant
implementations, where the latter are those not implementing
some of this stuff (but they guarantee that they comply to
the `core' features).
> 2) The ANSI types are a little bit more complicated than I thought. So here
> is my first shot:
[..]
Yep, I agree with all that you said there.
> 3) I don't think that we should care about this ancient far/near pointer
> stuff. It is already enough that there are different calling conventions
> on Windows platforms.
Some people always have be an exception... ;-)
Cheers,
Manuel
