- FFI - Haskell.org

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

05 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

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

02 Jun '03

> Using `newtype T = MkT Int8' or equivalent only works for foreign data > types whose representation is known. How do you deal with > C's "time_t", > for example? Or with C "struct" types? The user doesn't want to make > non-portable assumptions about what padding the C compiler is going > to insert. > > Like Haskell, Mercury allows data definitions with no body: > > :- type t. > > But to deal with cases like the ones mentioned above, > Mercury also allows the user to declare how such types are > represented in foreign languages, using `pragma foreign_type' > declarations: > > :- pragma foreign_type("C", t, "some_c_typename"). > > The Mercury compiler will generate appropriate glue code to > marshal and unmarshal values of that type. We have similar support in some of the Haskell FFI Tools. For example, using hsc2hs I can write: newtype CTime = CTime $(type time_t) and this will be converted into newtype CTime = CTime (Int32) (or whatever) when hsc2hs processes the source. Ok, it's language-dependent, but it has the advantage that it doesn't require any extra support from the compiler, and nothing needs to be added to the FFI spec. Similar mechanisms can be (and are) used for marshalling C structs without baking in the field offsets and types. Cheers, Simon

1 0

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

02 Jun '03

> I don't think we have much choice about whether undefined > values are part of > the type. If you can create a value of that type: > > x <- derefPtr (px :: Ptr T) I'm not following this. what exactly is derefPtr? The only analogous function I can think of is Foreign.peek: peek :: Storable a => Ptr a -> IO a but peek will unmarshal the value at the end of the Ptr into T, so T cannot be abstract. Cheers, Simon

3 2

ffi@haskell.org
by sms 30 May '03

30 May '03

1 0