Fergus Henderson <[EMAIL PROTECTED]> wrote,
> 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.
>
> > 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.
Yes, you are definitely having a point here. So, you mean
that you want to use the C feature that `struct *t' is the C
equivalent to `Ptr T' where
newtype T = T ()
In other words, you exploit the fact that in C an incomplete
struct introduces a unique new type. The code
void *p;
struct foo *x;
struct bar *y;
p = x; /* (1) */
y = x; /* (2) */
compiles at (1) without problems, but gives a warning at
(2).
I think that's actually a good idea. In fact, as this does
not raise a compile time error, but only a warning, it
doesn't prevent you at all from doing nasty things at the C
side (if you entertain such thoughts), but it helps you
tracking down bugs by having a look at the warnings, which
is a Good Thing.
Sven, how about making this a suggestion in the FFI spec?
If a system does not implement this, it doesn't break any
code, so we need not require it for compatibility, but it
simplifies debugging, so we might encourage such an
implementation. What do you think?
Cheers,
Manuel
