- FFI - Haskell.org

Lecture in Economics
by Clark Lewis 21 Sep '04

21 Sep '04

Dear Colleagues: Below is information concerning the Distinguished Lecture in Law and Economics on Tuesday March 5, 2002 at 4-30pm in Room 121 at GMUC's School of Law. Please join us on this occasion. Best Wishes Professor Zmijewski Peter Zmijewski graduated from Harvard College in 1968 and received a Ph.D. in Economics from Princeton in 1972. Peter Zmijewski was an Assistant Professor at Princeton from 1976-80. In 1984, he moved to the University of Michigan, first as an Associate Professor, then Professor of Economcis. Over the years, he has also been a visiting professor at a wide variety of universities and institutions throughout the world. -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm

1 0

C.Types
by "Daniel Müller" 07 Sep '04

07 Sep '04

Hallo, I try to use a Function calc, which is written in C (CalcType = Int): foreign import ccall calc :: CInt -> CInt -> CInt calculate :: Int -> Int -> CalcType calculate a b | ... | ... | otherwise = calc a b Unfortunately I got an error. What shall I do? best regards Daniel -- NEU: Bis zu 10 GB Speicher f�r e-mails & Dateien! 1 GB bereits bei GMX FreeMail http://www.gmx.net/de/go/mail

3 2

Re: PIC status
by Alastair Reid 02 Aug '04

02 Aug '04

[Redirected to ffi@... from cvs-ghc@...] Wolfgang Thaller wrote: > [lots of stuff about dynamic linking/ghc/PIC deleted] > So what's left to do is the following: > [...] > 7) Devise a way of telling GHC that a foreign import is imported from a > DLL (for Windows); something like __declspec(dllimport) in Windows C > compilers. We should have thought of this before the FFI spec was > finalized... > [...] Can you explain point 7? How is a foreign import from DLL different from a foreign import from statically linked files or from foreign import of a function pointer? Do you have to do something different to cause the DLL to be loaded or do you have to invoke the function using a different calling convention or both? -- Alastair Reid

2 1

RE: Fail: <<loop>> from finalizers and stuff
by Simon Marlow 05 Jul '04

05 Jul '04

On 04 July 2004 23:54, Sven Moritz Hallberg wrote: > Dear Foreign Function Interface, > > why does a program like the following fail with a "<<loop>>" exception > (using GHC 6.2 on MacOS X)? > > -----snip----- > import Foreign > > main = > do > f <- mkFinPtr finalizer > fp <- newForeignPtr f nullPtr > putStrLn "Hello World" > > finalizer ptr = putStrLn ("Finalize "++show ptr++".") > > foreign import ccall "wrapper" > mkFinPtr :: (Ptr () -> IO ()) -> IO (FinalizerPtr ()) > -----snap----- This is a FAQ, but you could be forgiven because the latest version of the FAQ on the web site doesn't have this entry yet. Here it is: <varlistentry> <term>I can't get finalizers to work properly. My program sometimes just prints <literal><<loop>></literal>.</term> <listitem> <para>Chances are that your program is trying to write a message to <literal>stdout</literal> or <literal>stderr</literal> in the finalizer. Handles have finalizers themselves, and since finalizers don't keep other finalized values alive, the <literal>stdout</literal> and <literal>stderr</literal> Handles may be finalized before your finalizer runs. If this happens, your finalizer will block on the handle, and probably end up receiving a <literal>NonTermination</literal> exception (which is printed as <literal><<loop>></literal>).</para> </listitem> </varlistentry> > Also, does the use of a "wrapper" import constitute a callback from C > in the sense of the following statement? > > "Whether a finalizer may call back into the Haskell system is system > dependent. Portable code may not rely on such callbacks." > > I.e. is the above code non-portable? Yes. > Why is the ForeignPtr interface constrained to finalizers that are > FunPtrs at all? I want to touch a ForeignPtr from another's finalizer > to satisfy a liveness dependency (as suggested in the spec). What is > the best way to do this? Good point. That comment in the spec is left over from when we had Haskell finalizers in the standard, and doesn't make sense any more. (Manuel - are you keeping errata somewhere? Or is someone else?) Doing this is now non-portable because some Haskell systems don't support calling back into Haskell from a finalizer. If you're committed to being non-portable, then the right way is to use the Foreign.Concurrent interface instead of the wrapper trick you use above. Cheers, Simon

1 0

Fail: <<loop>> from finalizers and stuff
by Sven Moritz Hallberg 05 Jul '04

05 Jul '04

Dear Foreign Function Interface, why does a program like the following fail with a "<<loop>>" exception (using GHC 6.2 on MacOS X)? -----snip----- import Foreign main = do f <- mkFinPtr finalizer fp <- newForeignPtr f nullPtr putStrLn "Hello World" finalizer ptr = putStrLn ("Finalize "++show ptr++".") foreign import ccall "wrapper" mkFinPtr :: (Ptr () -> IO ()) -> IO (FinalizerPtr ()) -----snap----- Also, does the use of a "wrapper" import constitute a callback from C in the sense of the following statement? "Whether a finalizer may call back into the Haskell system is system dependent. Portable code may not rely on such callbacks." I.e. is the above code non-portable? Why is the ForeignPtr interface constrained to finalizers that are FunPtrs at all? I want to touch a ForeignPtr from another's finalizer to satisfy a liveness dependency (as suggested in the spec). What is the best way to do this? Suppose I have: -----snip----- type Thing = Ptr () type Subthing = Ptr () foreign import ccall "new_thing" newThing :: IO Thing foreign import ccall "new_subthing" newSubthing :: Thing -> IO Subthing -----snap----- I can't do, as I would like: -----snip----- foreign import ccall "del_thing" delThing :: Thing -> IO () foreign import ccall "del_subthing" delSubthing :: Subthing -> IO () main = do p1 <- newThing p2 <- newSubthing p1 fp1 <- newForeignPtr delThing p1 fp2 <- newForeignPtr (\p -> delSubthing p >> touchForeignPtr fp1) p2 {- ...do more funny things... -} -----snap----- So because touchForeignPtr is a Haskell function, I must go through a wrapper. It seems strange to me that the Haskell storage manager would not be able to call Haskell routines as finalizers directly... Assuming that's really the only way to do it, I suppose my code would look like this, correct? -----snip----- foreign import ccall "&del_thing" delThing_p :: FunPtr (Thing -> IO ()) foreign import ccall "del_subthing" delSubthing :: Subthing -> IO () foreign import ccall "wrapper" mkFinPtr :: (Ptr () -> IO ()) -> FunPtr (Ptr () -> IO ()) main = p1 <- new_thing p2 <- new_subthing p1 fp1 <- newForeignPtr delThing_p p1 f <- mkFinPtr (\p -> delSubthing p >> touchForeignPtr fp1) fp2 <- newForeignPtr f p2 {- ...do the funky chicken... -} -----snap----- Thanks in advance, Sven Moritz PS: You're still great! PPS: Do you mind being called fifi? ;-)

1 0

RE: atomicModifyIORef
by Simon Marlow 28 Jun '04

28 Jun '04

On 25 June 2004 15:09, Daan Leijen wrote: > Ok, I never thought of that. However, isn't it the case > that I normally just want to get the old value back? > In that case, the current interface is not so friendly. > > Is anyone using this function to get something else than the > old/new value *and* where the computation is expensive? > > If not, maybe we should (also) provide a nicer interface? I've no objection to providing simpler versions of the more general interface - in fact I believe we discussed this when atomicModifyIORef was introduced. How about: atomicModifyIORef_ :: IORef a -> (a -> a) -> IO a atomicModifyIORef_ r f = atomicModifyIORef r (\a -> (f a, a)) If this turned out to be a common case that needs to be fast, then we can implement it using a primitive in GHC. Cheers, Simon

1 0

RE: [Haskell] ANNOUNCING: The Haskell Bookstore
by Simon Marlow 25 Jun '04

25 Jun '04

On 25 June 2004 11:30, Daan Leijen wrote: > Is there anyone who knows why "atomicModifyIORef" has type: > > IORef a -> (a -> (a, b)) -> IO b (1) > > Instead of: > > IORef a -> (a -> a) -> IO a (2) > > > It seems to me that returning the old value is always good > enough right? Here is an implementation of "atomicModifyIORef" > with the current type in terms of a function "proposedModifyIORef" > with type (2). > > atomicModifyIORef :: IORef a -> (a -> (a,b)) -> IO b > atomicModifyIORef ref f > = do old <- proposedModifyIORef ref (fst . f) > return (snd (f old)) Yes, but in your version you apply f to the old value twice, potentially duplicating an expensive computation. atomicModifyIORef isn't part of the FFI spec, BTW. Cheers, Simon

2 1

ANNOUNCING: The Haskell Bookstore
by John Meacham 25 Jun '04

25 Jun '04

The Haskell bookstore is now open :) The bookstore is an attempt to publish out-of-print books, scientific papers, and technical documentation relating to Haskell and Functional Programming in general which is not otherwise available in print. At the moment, the shop has * Simon Peyton Jones and David Lester's book on functional language implementation * The FFI specification. more titles shall be forthcoming. I am doing this as a non-profit venture, mainly because I really want some of these books in print :) So the cost is simply the printing cost plus expenses which will hopefully keep things afordable for everyone interested. the bookstore is at http://www.cafeshops.com/haskell_books and a wiki page describing it and allowing people to add to a wishlist and faq is at http://haskell.org/hawiki/HaskellBookstore I am always looking for new material, so any aid in tracking down copyright holders or orignal TeX files for anything desired would be apreciated. Plus, improving the documentation such as the GHC manual and FFI spec is doubleplusgood, as I can regularly pull down the cvs versions and keep the books up to date with the latest developments and good documentation benefits the community as a whole. Please let me know as soon as possible if anyone has any trouble with a printed version, as this is print-on-demand, I can incorporate changes to future editions right away. Oh, and I can't really afford to be sued, so if you think I am infringing on your copyright, send me a note before breaking out the lawyers and I will be happy to work something out :) John -- John Meacham - ⑆repetae.net⑆john⑈

3 2

Calling convention for FinalizerPtr
by Simon Marlow 14 Jun '04

14 Jun '04

Something came up on the GHC list which made me realise that a slight clarification is needed in the FFI spec. FinalizerPtr is defined as: type FinalizerPtr a = FunPtr (Ptr a -> IO ()) However, there is no way to specify what the calling convention for a FunPtr is. The calling convention is specified by the foreign import declaration when calling one: foreign import ccall "dynamic" foo ... In the case of finalizers, the ForeignPtr implementation must pick a calling convention to call the finalizer with. In GHC, we pick ccall. This means that you can only use finalizers which expect the ccall calling convention, something that isn't specified in the FFI addendum, or the documentation for newForeignPtr. What's the right thing to do here? The simple thing is just to document the restriction, but that might be entirely wrong on systems that don't support the ccall convention, for example. So perhaps there is a per-platform fixed calling convention for finalizers. Perhaps a FunPtr should remember its calling convention? But then what is the calling convention for nullFunPtr, or the FunPtr returned by castPtrToFunPtr? Or perhaps we should have different versions of mkForeignPtr for each calling convention? That doesn't sound too attractive either. Cheers, Simon

1 0

[Fwd: cvs commit: fptools/libraries/base/Foreign/C Types.hs fptools/libraries/base/System CPUTime.hsc Directory.hs Time.hsc fptools/libraries/base/System/Posix Types.hs fptools/libraries/base/include CTypes.h]
by Sven Panne 14 Jun '04

14 Jun '04

I've just commited a change to the fptools repository, proposing a minor change in the FFI spec, see below. Comments welcome. Cheers, S. -------- Original Message -------- Subject: cvs commit: fptools/libraries/base/Foreign/C Types.hs fptools/libraries/base/System CPUTime.hsc Directory.hs Time.hsc fptools/libraries/base/System/Posix Types.hs fptools/libraries/base/include CTypes.h Date: Sun, 13 Jun 2004 14:03:47 -0700 From: Sven Panne <panne(a)glass.cse.ogi.edu> To: cvs-libraries(a)haskell.org panne 2004/06/13 14:03:47 PDT Modified files: libraries/base/Foreign/C Types.hs libraries/base/System CPUTime.hsc Directory.hs Time.hsc libraries/base/System/Posix Types.hs libraries/base/include CTypes.h Log: Changes related to arithmetic types: * Renamed macros NUMERIC_FOO to ARITHMETIC_FOO to match C99-speak * ARITHMETIC_TYPEs now have a Real instance, otherwise they are quite useless. Note that this differs from the FFI spec, but the spec should very probably changed in this respect. * Some changes to fix the wrong assumption that CTime/CClock are integral types, C99 in fact guarantees only that they are arithmetic types. This has been accomplished by using realToInteger = round . realToFrac :: Real a => a -> Integer instead of fromIntegral for CTime/CClock. I'm not sure if we could do better, going via Double seems to be overkill, but I couldn't think of a better way. GHC could e.g. use RULES here. Improvements welcome. Revision Changes Path 1.22 +2 -2 fptools/libraries/base/Foreign/C/Types.hs 1.15 +5 -4 fptools/libraries/base/System/CPUTime.hsc 1.25 +2 -1 fptools/libraries/base/System/Directory.hs 1.26 +7 -4 fptools/libraries/base/System/Time.hsc 1.14 +3 -3 fptools/libraries/base/System/Posix/Types.hs 1.8 +12 -13 fptools/libraries/base/include/CTypes.h _______________________________________________ Cvs-libraries mailing list Cvs-libraries(a)haskell.org http://www.haskell.org/mailman/listinfo/cvs-libraries

1 1