December 2002 - FFI - Haskell.org

Finalizers: conclusion?
by Simon Marlow 24 Jan '03

24 Jan '03

Ok, I'm sad to say that the problem we recently uncovered to do with finalizers sharing values with the rest of the program essentially kills off the possibility of doing Haskell finalizers in systems without proper concurrency support. I'm rather embarassed that I didn't notice this before; sorry for wasting everyone's time :-( Let's keep C finalizers for the FFI spec. In GHC I imagine we'll continue to offer Haskell finalizers as an extension, but I haven't decided on an interface yet (suggestions welcome). >From now on I intend to keep track of a strict quota that prevents me from writing more email than code :-) Cheers, Simon

6 8

White space in ccall impents
by Ian Lynagh 22 Jan '03

22 Jan '03

Is it just me or does the FFI spec not explain what whitespace is needed between the components of the ccall impent? 4.1.1 is the obvious place for it to be. In particular, even after reading between the lines, questions like "are multiple spaces between static and fname allowed", "is a space between & and cid allowed (or required)" and "are tabs allowed" seem to remain unanswered. Thanks Ian

3 5

["Simon Marlow" <simonmar@microsoft.com>] RE: cvs commit: fptools/libraries/base/Foreign ForeignPtr.hs
by Alastair Reid 22 Jan '03

22 Jan '03

[Thread moved from the library cvs mailing list] Simon Marlow: > - Fix the Eq instance for ForeignPtr to match the behaviour > specified by the spec. Two ForeignPtrs are equal iff their > underlying Ptrs are equal (previously they were equal iff they were > the same ForeignPtr). Alastair Reid: > Hmmm, the Hugs implementation goes for 'same foreignptr' and, to me, > that seems to make more sense. > > I wonder why the spec changed the semantics from that in the > Hugs-GHC spec? Simon Marlow: > I don't have any strong opinions on the matter, I just changed it to > match the spec because someone complained. > > Do you have an example where the previous behaviour is more useful? > Perhaps it should be brought up on the FFI list. I don't have a really compelling example just a nagging feeling and worry that a design is being changed without (as far as I can recall) any discussion of the matter. Here's some questions that might help understand the difference: 1) Is there any practical difference between the old semantics and the new? There used to be a big difference because ForeignObjects supported an operation to replace the underlying Ptr. Equality on mutable objects is clearly different from equality on the contents of the mutable objects. But, ForeignPtrs with the same Ptr but different finalizers are different and the finalizer list _is_ mutable so there is a useful difference. The difference between two ForeignPtrs which contain the same Ptr is especially clear if we think about what happens if the first one dies before the second or the second is the first to die. 2) Can either semantics be implemented in terms of something we already have? We can implement the new semantics using castForeignPtrToPtr. There's no way to implement the old semantics using other existing operations. Even if there was a way to extract the list of finalizers (and assuming we're happy using pointer equality on the finalizer functions), we still couldn't implement it because ForeignPtrs are, effectively, mutable objects. In short, I can see that switching to the new semantics (ForeignPtr equality == equality of contents) removes something we had before and doesn't add anything new but I don't have any examples of where it is actually useful. (I also have no examples of where the new semantics is useful.) I should also say that I have no strong feelings on the matter - I'd just like to hear someone argue that the change is an improvement or be pointed at an old discussion on the subject. -- Alastair

4 7

call china 6.2¢ www.callez.com
by promotion＠callez.com 01 Jan '03

01 Jan '03

1 0

Green card 2003 y�l� kay�tlar�m�z ba�lam��t�r.
by G��MENL�K/ABD 27 Dec '02

27 Dec '02

1 0

lesson about ffi
by Po Popo 14 Dec '02

14 Dec '02

Alastair Reid, really thanks by the attention. Could you send me that tutorial, i think it can help me to understand more about ffi and consequently help me on my lesson. If you have something like presentations like (.ppt Microsoft Power Point) would be much important to me read them. I'm really thankful. If someone more could help me, please send me help like tutorials, examples using ffi etc. Thanks a lot. Popebox --------------------------------- Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now

1 0

lesson about ffi
by Po Popo 12 Dec '02

12 Dec '02

Hello, I study computer engeneering at University of Pernambuco-BRAZIL .I have to present a lesson about FFI and i need some help, like explains where i can get the right information and tutorials. Its very important to me. Since now im thankful. Popebox --------------------------------- Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now

2 1

RE: ForeignPtr query
by Simon Marlow 11 Dec '02

11 Dec '02

> 1. part of this BDD library uses ints (not pointers) to identify > garbage-collectable objects. there's nothing in the FFI to > cope with this AFAICS. i could: > > - hack the library (but would prefer not to). > > - say the functions in question deal with Ptr CInt, and hope > sizeof(int) > == sizeof(int *) on all platforms i need to run this on (yuk). > > - plead for a general "stick this arbitrary (small) C object in an > optimiser-impervious box" generalisation of ForeignPtr. There was a proposal for such a thing kicking around recently, and I think there's no real problems with it. Although you're the first person to come along with a real application, to my knowledge. Please feel free to mail ffi(a)haskell.org and make a case, I'd say there's a pretty good chance it'll get adopted. > 2. how do i import a function pointer under ghc5.02? in 5.04 i say: > > foreign import ccall "&bdd_reorder_stable_window3" > bdd_reorder_stable_window3 :: FunPtr (BDDManager -> IO ()) > > and that works (i.e. i can treat it like any other Haskell function). 5.02 had something called 'foreign label', which does the same thing. Check the docs for details. > 3. i'd like to see some array marshalling code that copes > with lists of > ForeignPtrs, such as: > > -- | Marshall a list of ForeignPtrs. Same structure as withArray0. > withForeignArray0 :: Ptr a > -> [ForeignPtr a] > -> (Ptr (Ptr a) -> IO b) > -> IO b > withForeignArray0 marker vals f = > allocaArray0 len > (\ptr -> do pokeArray0 marker ptr $ map foreignPtrToPtr vals > res <- f ptr > mapM touchForeignPtr vals > return res) > where len = length vals ITYM: withForeignArray0 fps io = withMany withForeignPtr fps $ \ps -> withArray0 nullPtr ps io > the problem is it isn't as usefully polymorphic as the corresponding > withArray0 function (e.g. consider [(ForeignPtr a, ForeignPtr > a)]). ideas? What type do you want for it? Cheers, Simon

2 1

ForeignPtr query
by Peter Gammie 03 Dec '02

03 Dec '02

g'day everyone, as Manuel said before, i've been trying to give a BDD library a pretty Haskell interface (give me a shout if this is of interest to you). i have a few queries: 1. part of this BDD library uses ints (not pointers) to identify garbage-collectable objects. there's nothing in the FFI to cope with this AFAICS. i could: - hack the library (but would prefer not to). - say the functions in question deal with Ptr CInt, and hope sizeof(int) == sizeof(int *) on all platforms i need to run this on (yuk). - plead for a general "stick this arbitrary (small) C object in an optimiser-impervious box" generalisation of ForeignPtr. 2. how do i import a function pointer under ghc5.02? in 5.04 i say: foreign import ccall "&bdd_reorder_stable_window3" bdd_reorder_stable_window3 :: FunPtr (BDDManager -> IO ()) and that works (i.e. i can treat it like any other Haskell function). 3. i'd like to see some array marshalling code that copes with lists of ForeignPtrs, such as: -- | Marshall a list of ForeignPtrs. Same structure as withArray0. withForeignArray0 :: Ptr a -> [ForeignPtr a] -> (Ptr (Ptr a) -> IO b) -> IO b withForeignArray0 marker vals f = allocaArray0 len (\ptr -> do pokeArray0 marker ptr $ map foreignPtrToPtr vals res <- f ptr mapM touchForeignPtr vals return res) where len = length vals the problem is it isn't as usefully polymorphic as the corresponding withArray0 function (e.g. consider [(ForeignPtr a, ForeignPtr a)]). ideas? IMHO, as many common usage patterns requiring touchForeignPtr as possible should be stuck in the library... what form this might take remains to be seen. cheers peter

1 0