June 2003 - FFI - Haskell.org

RE: ANN: H98 FFI Addendum 1.0, Release Candidate 10
by Simon Marlow 08 Jun '03

08 Jun '03

> 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. Let's be clear about the role of Point here: it is a dummy type argument to Ptr, used to disambiguate the type 'Ptr Point' from any other kind of Ptr. It is for type-safety in the Haskell code. Additionally, the type argument to Ptr is used to resolve overloading when doing marshalling using the Storable class, but we're not using that facility here because no marshalling is going on. There definitely aren't any values of type Point, so I don't see why it needs a semantics. The semantics of empty data declarations seems like an entirely orthogonal issue, and I don't see any problem with the current semantics for empty data declarations, which is a completely natural degenerate case of ordinary data declarations. > > 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). I don't agree with that last sentence: there's no trickery going on; it doesn't matter how many values of the type Point there are. I could use any Haskell type with the same results. Let me say this another way: the type argument to Ptr in no way represents the type of the foreign data. It is used to resolve overloading and to disciminate pointer types in Haskell marshalling code, that's all. There is no link between the semantics of the Haskell type and the semantics of the foreign type (whatever that might be), and we shouldn't confuse the issue by pretending that there is. Cheers, Simon

4 4

RE: How to access defines and enums in a convenient way?
by Simon Marlow 06 Jun '03

06 Jun '03

> I am doing some wrappers for c functions, and I need to > access defines, enums, and structs. > > I am doing this by writing access functions in c, so that I can call > them from Haskell. > > Is there a way to write this c code inline in the Haskell > module? You want to use a tool to make all this easier. There are various tools available: green-card, c2hs, and hsc2hs are the most commonly-used ones these days. Alastair Reid wrote a good comparison of the various tools (can't remember the link off hand though). There are examples of hsc2hs code in the libraries - particularly fptools/libraries/unix has examples of doing defines, enums and structs. Examples of green-card stuff can be found in fptools/libraries/HGL and fptools/libraries/X11. Take a look at Manuel's GtkHS for c2hs examples. Cheers, Simon

4 4

How to access defines and enums in a convenient way?
by Martin Norbäck 06 Jun '03

06 Jun '03

I am doing some wrappers for c functions, and I need to access defines, enums, and structs. I am doing this by writing access functions in c, so that I can call them from Haskell. Is there a way to write this c code inline in the Haskell module? Since any implementation of FFI must do this via C anyway (to access the header files), it could simply inline the code as well. It's a bit of a bother to have to specify the object files for the access functions when compiling a Haskell program, especially since I am writing library modules and the program using the library shouldn't need to bother with extra object files. Regards, Martin -- Martin Norbäck d95mback(a)dtek.chalmers.se Kapplandsgatan 40 +46 (0)708 26 33 60 S-414 78 GÖTEBORG http://www.dtek.chalmers.se/~d95mback/ SWEDEN OpenPGP ID: 3FA8580B

2 1

Italian-crafted Rolex - only $65 - $140!! Free SHIPPING ! !
by tony2003＠yahoo.ca 06 Jun '03

06 Jun '03

1 0

RE: ANN: H98 FFI Addendum 1.0, Release Candidate 10
by Simon Marlow 05 Jun '03

05 Jun '03

> > > > data Point > > > > foreign import getMousePos :: Ptr Point -> IO () > > > > foreign import getX :: Ptr Point -> IO Int > > > > foreign import getY :: Ptr Point -> IO Int > > vs > > > data Point = Point (Ptr Point) > > foreign import getMousePos :: Point -> IO () > > I like the second idiom. You are right that there is no need for > the application programmer to know whether pointers are involved, > because even in the first style, it is not possible to 'peek' inside > a Ptr Point to get the `actual' Point value. So why not hide the > pointer altogether? Yes. I presume that should be 'newtype' rather than 'data'? Cheers, Simon

2 1

RE: ANN: H98 FFI Addendum 1.0, Release Candidate 10
by Simon Marlow 04 Jun '03

04 Jun '03

> Manuel M T Chakravarty <chak(a)cse.unsw.edu.au> writes: > > > -=- Changes since RC 9 > > > > * 6.2: All the types in CTypes must be newtypes that are exported > > abstractly. > > This change makes things highly inconvenient in nhc98. A newtype > can only be passed across the FFI in nhc98 if we have enough > information to determine the original type that is being renamed. > If Foreign.C.Types exports them abstractly, then currently we do not > have that information, and so these types cannot be used at all! > > I am not suggesting that the newtype constructors should necessarily > be part of the API seen by the user, but the problem comes down to a > known deficiency in nhc98's interface file conventions. How about exporting them non-abstractly for nhc98 only, and adding a comment to explain why the workaround is necessary? Cheers, Simon

3 2

ANN: H98 FFI Addendum 1.0, Release Candidate 10
by Manuel M T Chakravarty 04 Jun '03

04 Jun '03

I have incorporated the feedback to RC 9 into RC 10, which you can get, as always, from http://www.cse.unsw.edu.au/~chak/haskell/ffi/ I also tracked the addition of `FinalizerPtr' in fptools. If there are no further suggestions, I will post RC 10 on the main list for final (hopefully!) review. Cheers, Manuel -=- Changes since RC 9 * 1: Mentioning interaction with foreign threads as an open problem. * 2 & 3: Removed `threadsafe' again, as the proposal for thread support is still evolving and it is not yet clear whether a new safety level is required. * 5.5: Added the type synonym `FinalizerPtr' and rewrite the documentation of finalizers. * 5.6: Clarified the description of `StablePtr' * 5.8: Added `finalizerFree' * 6.2: All the types in CTypes must be newtypes that are exported abstractly.

8 12

RE: ANN: H98 FFI Addendum 1.0, Release Candidate 10
by Simon Marlow 03 Jun '03

03 Jun '03

> On Monday 02 June 2003 2:32 pm, Simon Marlow wrote: > > > Ok. But I still don't understand why the whole discussion > isn't moot. > > I can't see how to acquire a value of type T that isn't bottom. > > Whether you can acquire values of this type or not, we need > to give it a semantics. > > We know that T must contain bottom. Not necessarily - GHC's primitive types don't contain bottom. But I'm probably just being awkward, since I really don't understand what it is you're trying to do here. > > Could you give an example? > > No , I probably can't come up with an example as things stand > at the moment. > But who knows what changes we might make in the future and > when we do, we're > bound to do better if our semantics relfects reality instead > of relying on a trick. I'd be happy for semantics to reflect reality - but what *is* the reality that you're trying to model? And what do you mean by a trick? 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? I think an example would really help. Invent some syntax and extra features if you need to! Cheers, Simon

2 1

RE: ANN: H98 FFI Addendum 1.0, Release Candidate 10
by Simon Marlow 02 Jun '03

02 Jun '03

> > I'm not following this. what exactly is derefPtr? The only > analogous > > function I can think of is Foreign.peek: > > Sorry, I meant peek. > > > but peek will unmarshal the value at the end of the Ptr into T, so T > > cannot be abstract. > > Sorry, I was just trying to show how to create a value of type > T which might be bottom. It would have been easier to use: > > t :: T > t = undefined Ok. But I still don't understand why the whole discussion isn't moot. I can't see how to acquire a value of type T that isn't bottom. Could you give an example? Cheers, Simon

3 2

RE: ANN: H98 FFI Addendum 1.0, Release Candidate 10
by Simon Marlow 02 Jun '03

02 Jun '03

> On 02-Jun-2003, Simon Marlow <simonmar(a)microsoft.com> wrote: > > > > I can't see how to acquire a value of type T that isn't bottom. > > By calling a function defined using the FFI, of course. But the FFI lists the types that may be returned by a foreign function, and T is not one of them. Are you suggesting we ought to be able to define new primitive types? Cheers, Simon

3 2