On 28-Mar-2000, Manuel M. T. Chakravarty <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Marcin 'Qrczak' Kowalczyk) wrote,
> > What woyld GtkText* map to? GtkText is a typedef to an opaque struct.
>
> One idea that we discussed is that `GtkText*' would map to
> `Ptr GtkText', where `GtkText' is opaque und would indeed be
> implemented as
>
> newtype GtkText = GtkText ()
>
> This way, we wouldn't try to model Haskell's type system in
> C or the other way around, but just increase type safety by
> using types such as `GtkText' as Skolem variables that only
> match with themselves in Haskell's type checker.
Yes -- that kind of thing, plus the equivalent for the other direction
(exporting Haskell to C), is what I was getting at when
I stressed the importance of preserving static type information
across the FFI boundary.
> As Sven pointed out, it was suggested that we collect some
> experience with this definition before including it into the
> FFI standard proposal. The next version of C->HS will
> support `Ptr a' to gather some experience with its use.
Great!
> PS: This proposal does not address the problem of cross-FFI
> type consistency raised by Fergus. It only makes the
> Haskell binding of C code more type safe.
Actually it does address one half of the cross-FFI type safety problems I
was talking about. The other half is just doing the same thing (or at least
as much of it as is possible) for the C binding of Haskell code.
I wasn't suggesting that you try to address the more difficult issue of
providing full access to compound C data types from Haskell or vice versa.
That would be a nice bonus, but it's a lot harder to implement.
I'd be happy if you keep compound data types as opaque when viewed
from the other side of the FFI interface. I just want them to be
as type-safe as possible.
Debugging problems that turn out to be due to type errors across a language
interfacing boundary is in my experience difficult and time-consuming, because
such bugs often manifest themselves in difficult ways (e.g. seg fault in the
HLL code) and because the debugging tools generally don't have great support
for debugging across the language interfacing boundary.
--
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.
