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 _______________________________________________ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi