ANN: H98 FFI Addendum 1.0, Release Candidate 10

[Alastair Reid]

On Tuesday 03 June 2003 10:15 am, Simon Marlow wrote:

> > We know that T must contain bottom.
>
> Not necessarily - GHC's primitive types don't contain bottom.

Of course, GHC's primitive types aren't in the standard.

> But I'm probably just being awkward, since I really don't understand
> what it is you're trying to do here.

I'm trying to give a semantics to the existing feature of using empty data 
declarations with the ffi.

Second to that, I am checking that the existing syntax matches the semantics.

I definitely do not want to add the ability to marshal these types because we 
already have a fine way of dealing with them (i.e., a wide range of 
explicitly sized types plus hsc2hs/autoconf).
  
> I'd be happy for semantics to reflect reality - but what *is* the
> reality that you're trying to model?

We routinely use code like this:

  data Point
  foreign import getMousePos :: Ptr Point ->  IO ()
  foreign import getX :: Ptr Point -> IO Int
  foreign import getY :: Ptr Point -> IO Int

The idea being that:

1) there is a foreign type (which might be called Point, MousePos, point_t, 
struct point or whatever)

2) that we have a pointer to it

3) that the thing we have a pointer to can take on a number of different 
values.  We don't know what the values are but this doesn't mean they don't 
exist.

> And what do you mean by a trick?

It is possible that, since we cannot directly observe values of foreign types, 
we can safely model the type as having just one value (bottom) or, perhaps 
even no values at all.  By this I mean that exactly the same properties can 
be proved whether we use an accurate model or a simplified model.

But, it is a trick because we know that there is not just one (or zero) values 
in that type (at least, for most types).

> As far as I can tell, you want a type T that represents a foreign
> object.  What is the representation of this foreign object?  How is it
> marshalled to and from the foreign language?

We already have types which represent foreign types.
We can give this existing feature a semantics without having to define its 
representation or add marshalling.

> I think an example would really help.  Invent some syntax and extra
> features if you need to!

The Point example above is what I want (i.e., what we already have).

I'm tempted to change the syntax to something like:

  foreign import type Point

to make it a little more obvious when you find it in source code but apart 
from that I'm not contemplating any change in implementations.

--
Alastair Reid