November 2002 - FFI - Haskell.org

Re: ForeignPtr-related signatures
by Sven Panne 18 Nov '02

18 Nov '02

Simon Marlow wrote: > [...] There was this, from Dean Herrington: > > http://haskell.cs.yale.edu/pipermail/ffi/2002-October/000940.html > > I don't have any strong feelings (I rarely do, where names are > concerned). I would be happy with his proposal. We can leave the IORef stuff in IOExts as it is and use the new signatures and functions in Data.IORef. The only annoying thing is the signature of Data.IORef.modifyIORef, but we could declare the old signature as a bug... :-] Cheers, S.

1 0

RE: ForeignPtr-related signatures
by Simon Marlow 18 Nov '02

18 Nov '02

> That's what I expected. Would it be possible to include the > new functions > in 5.04.2? OK, that's an API change, too, but simple > additions are rather > harmless. If we don't include this stuff now, there is no > useful common ForeignObj API for GHC/Hugs/NHC in the near future. Ok, I suppose we could bend the rules a little in this case, as long as we don't change the behaviour of any existing functions. > > [...] Also still unresolved is what to do about > atomicModifyIORef and > > friends, BTW. > > I remember atomicModifyIORef, but what are its "friends" > exactly? PVars > have died, IIRC, and some cunning constraints on the > execution order of > finalizers were rejected, too. There was this, from Dean Herrington: http://haskell.cs.yale.edu/pipermail/ffi/2002-October/000940.html I don't have any strong feelings (I rarely do, where names are concerned). Cheers, Simon

1 0

RE: ForeignPtr-related signatures
by Simon Marlow 18 Nov '02

18 Nov '02

> Just some small questions: Are we really going to change the > signatures of > newForeignPtr and addForeignPtrFinalizer from those which GHC > has for ages > to the new "C finaliser only" ones? Why don't we use other names and > deprecate the old ones? And what are the plans in this area for GHC > 5.04.2? GHC 5.04.2 won't adopt any library changes, as it's only a patchlevel release (we don't make API changes between patchlevels, only major releases). I don't really mind too much what names we use, I'd be fine with keeping the current names but changing the types if that's the concensus. Also still unresolved is what to do about atomicModifyIORef and friends, BTW. Cheers, Simon

1 0

ForeignPtr-related signatures
by Sven Panne 18 Nov '02

18 Nov '02

Just some small questions: Are we really going to change the signatures of newForeignPtr and addForeignPtrFinalizer from those which GHC has for ages to the new "C finaliser only" ones? Why don't we use other names and deprecate the old ones? And what are the plans in this area for GHC 5.04.2? Maybe this has been discussed already, but a brain buffer overflow occured while reading the finaliser thread... %-} Note that I don't have very strong feelings about this, using the new signatures even in GHC will pose no real problems: The type checker will catch old code and the current interface is easy to emulate via "foreign import wrapper". Cheers, S.

2 1

HDirect
by Martin Huschenbett 13 Nov '02

13 Nov '02

I tried to build HDirect 0.17. After running `make boot' and `make' successfully, I tried to run `make lib', but I got the follwing message: > make lib make -C lib boot && make -C lib all make[1]: Entering directory `/home/martin/download/haskell/packages/hdirect-0.17/lib' ghc -package lang -M -optdep-f -optdep.depend -optdep-o -optdepo -static -fglasgow-exts -fno-prune-tydecls -recomp -fvia-C Pointer.lhs HDirect.lhs PointerPrim.hs Com.lhs Automation.lhs AutoPrim.hs ComPrim.hs StdTypes.hs SafeArray.hs ComException.lhs TypeLib.hs Connection.hs ComDll.lhs ComServ.lhs ClassFactory.lhs StdDispatch.lhs ConnectionPoint.lhs EnumInterface.lhs ExeServer.lhs make[1]: Leaving directory `/home/martin/download/haskell/packages/hdirect-0.17/lib' make[1]: Entering directory `/home/martin/download/haskell/packages/hdirect-0.17/lib' ghc -package lang -fvia-C -static -fglasgow-exts -fno-prune-tydecls -recomp -fvia-C -c SafeArray.hs -o SafeArray.o -osuf o /tmp/ghc6009.hc: In function `r3lT_fast2': /tmp/ghc6009.hc:163: warning: implicit declaration of function `SafeArrayUnlock' /tmp/ghc6009.hc: In function `r3lV_fast2': /tmp/ghc6009.hc:272: warning: implicit declaration of function `SafeArrayUnaccessData' /tmp/ghc6009.hc: In function `r3lX_fast3': /tmp/ghc6009.hc:385: warning: implicit declaration of function `SafeArrayRedim' /tmp/ghc6009.hc: In function `r3lZ_fast4': /tmp/ghc6009.hc:516: warning: implicit declaration of function `SafeArrayPutElement' /tmp/ghc6009.hc: In function `r3m1_fast4': /tmp/ghc6009.hc:662: warning: implicit declaration of function `SafeArrayPtrOfIndex' /tmp/ghc6009.hc: In function `r3m3_fast2': /tmp/ghc6009.hc:801: warning: implicit declaration of function `SafeArrayLock' /tmp/ghc6009.hc: In function `r3m5_fast4': /tmp/ghc6009.hc:917: warning: implicit declaration of function `SafeArrayGetUBound' /tmp/ghc6009.hc: In function `r3m7_fast4': /tmp/ghc6009.hc:1063: warning: implicit declaration of function `SafeArrayGetLBound' /tmp/ghc6009.hc: In function `r3m9_fast2': /tmp/ghc6009.hc:1202: warning: implicit declaration of function `SafeArrayGetElemsize' /tmp/ghc6009.hc: In function `r3mb_fast4': /tmp/ghc6009.hc:1318: warning: implicit declaration of function `SafeArrayGetElement' /tmp/ghc6009.hc: In function `r3md_fast2': /tmp/ghc6009.hc:1457: warning: implicit declaration of function `SafeArrayGetDim' /tmp/ghc6009.hc: In function `r3mf_fast2': /tmp/ghc6009.hc:1566: warning: implicit declaration of function `SafeArrayDestroyDescriptor' /tmp/ghc6009.hc: In function `r3mh_fast2': /tmp/ghc6009.hc:1675: warning: implicit declaration of function `SafeArrayDestroyData' /tmp/ghc6009.hc: In function `r3mj_fast2': /tmp/ghc6009.hc:1784: warning: implicit declaration of function `SafeArrayDestroy' /tmp/ghc6009.hc: In function `r3ml_fast4': /tmp/ghc6009.hc:1900: warning: implicit declaration of function `SafeArrayCreate' /tmp/ghc6009.hc:1900: warning: assignment makes pointer from integer without a cast /tmp/ghc6009.hc: In function `r3mn_fast3': /tmp/ghc6009.hc:2041: warning: implicit declaration of function `SafeArrayCopy' /tmp/ghc6009.hc: In function `r3mp_fast3': /tmp/ghc6009.hc:2169: warning: implicit declaration of function `SafeArrayAllocDescriptor' /tmp/ghc6009.hc: In function `r3mr_fast2': /tmp/ghc6009.hc:2291: warning: implicit declaration of function `SafeArrayAllocData' /tmp/ghc6009.hc: In function `r3mt_fast3': /tmp/ghc6009.hc:2404: warning: implicit declaration of function `SafeArrayAccessData' /tmp/ghc6009.hc: In function `s3uA_entry': /tmp/ghc6009.hc:2994: `primSafeArrayDestroy' undeclared (first use in this function) /tmp/ghc6009.hc:2994: (Each undeclared identifier is reported only once /tmp/ghc6009.hc:2994: for each function it appears in.) /tmp/ghc6009.hc: In function `s3Cq_2_alt': /tmp/ghc6009.hc:3125: `primSafeArrayDestroy' undeclared (first use in this function) /tmp/ghc6009.hc: In function `s3CD_2_alt': /tmp/ghc6009.hc:3543: `primSafeArrayDestroy' undeclared (first use in this function) /tmp/ghc6009.hc: In function `s3w6_entry': /tmp/ghc6009.hc:3705: `primSafeArrayDestroy' undeclared (first use in this function) /tmp/ghc6009.hc: In function `s3CP_ret': /tmp/ghc6009.hc:3820: warning: assignment makes pointer from integer without a cast make[1]: *** [SafeArray.o] Fehler 1 make[1]: Leaving directory `/home/martin/download/haskell/packages/hdirect-0.17/lib' make: *** [lib] Fehler 2 Is there anybody, who can help me? Or is there maybe any newer version of HDirect, that is easier to compile? THX, Huschi!

1 0

Re: ["Simon Marlow" <simonmar@microsoft.com>] RE: cvs commit: fptools/libraries/base/Foreign ForeignPtr.hs
by cwitty＠newtonlabs.com 12 Nov '02

12 Nov '02

Alastair Reid <alastair(a)reid-consulting-uk.ltd.uk> writes: > > perhaps ForeignPtr should not be an instance of Eq so people can > > provide their own? > > Note that if we did this, we'd want to consider adding an operation > > eqForeignPtr :: FP a -> FP a -> Bool > > FP b -- possible variant but not very useful > > which lets people test equality of the container and not the contents. > > In fact the more I think on it, the more convinced I am that the Eq > instance should compare contaner equality and not contents equality. > The reason is that I believe Eq instances should follow the following > design rule: > > Eq instances should compute observational equivalence > > I believe this is satisfied by all Haskell98 types, all the usual > extensions (IORefs and friends) and by derived instances of datatypes. My vote would be for Eq ForeignPtr to test the contents. I guess the correspinding design rule would be: Eq instances should compute the most precise equivalence which is commonly useful. I would say that for IORef, etc., observational equivalence is "commonly useful", so that's the correct definition of Eq. On the other hand, for ForeignPtr, contents equality is "commonly useful". We've seen the example of the BDD package; contents equality will also be useful for any C library with an "intern" or "hash cons" operation. As far as I know, nobody has yet come up with a use for container equality for ForeignPtr, but I agree that we should have an eqForiegnPtr just in case. Carl Witty

1 0

Re: ForeignPtr
by Ashley Yakeley 09 Nov '02

09 Nov '02

At 2002-11-08 02:39, Ross Paterson wrote: >On Fri, Nov 08, 2002 at 10:32:20AM -0000, Simon Marlow wrote: >> Ross's proposal provides a subtly different mechanism. > >It's not mine -- Ashley Yakeley proposed it in > >http://www.haskell.org/pipermail/glasgow-haskell-users/2001-September/0022 >89.html I've pretty much forgotten my mind of the time. But whatever I said, I'm sure it was an excellent idea... -- Ashley Yakeley, Seattle WA

1 0

RE: ForeignPtr
by Simon Marlow 08 Nov '02

08 Nov '02

John Meacham writes: > this already exists in GHC, a side effect of Weak pointers is > that they allow finalizers to be assosiated with any value. > > http://haskell.org/ghc/docs/latest/html/base/System.Mem.Weak.html > > === > addFinalizer :: key -> IO () -> IO () > > A specialised version of mkWeakPtr, where the Weak object returned is > simply thrown away (however the finalizer will be remembered by the > garbage collector, and will still be run when the key becomes > unreachable). > === Ross's proposal provides a subtly different mechanism. In fact, it's a safe way to use finalizers on arbitrary objects - but the price you pay is having to explicitly delimit uses of the object from the IO monad. The key function in the new scheme is withFinalized (or withProxy or whatever you want to call it): withFinalized :: Finalized a -> (a -> IO b) -> IO b which "opens" the object for use, and prevents it from being finalized until the IO action completes. The problem with using System.Mem.Weak.addFinalizer to place finalizers on arbitrary objects is that compiler transformations can alter the lifetime of the object in ways that you don't expect. This is fine for the use we originally designed it for, memo tables, but for most other uses it isn't suitable. The only things that can safely have finalizers attached are "primitive" objects which are explicitly created in the IO monad - these objects can't be arbtrarily duplicated by the compiler, so their lifetime is more predictable. IORefs, MVars, ForeignPtrs and IOArrays fall into this category. Cheers, Simon

2 1

ForeignPtr
by Ross Paterson 08 Nov '02

08 Nov '02

Sorry to ask this again, but I didn't understand the answer last time, and the need to explicitly free StablePtr's, Haskell FunPtr's and close foreign handles, etc, is surely a serious wart in the FFI spec. In Sept 2001 Ashley Yakeley asked why ForeignPtr couldn't be generalized, i.e. an interface like (slightly modified from the original): data Proxy a -- abstract; for GHC, = Proxy ForeignObj# instance Eq (Proxy a) type Finalizer a = FunPtr (a -> IO ()) -- or IO () for Haskell finalizers newProxy :: Finalizable a => a -> Finalizer a -> IO (Proxy a) addFinalizer :: Finalizable a => Proxy a -> Finalizer a -> IO () withProxy :: Finalizable a => Proxy a -> (a -> IO b) -> IO b touchProxy :: Finalizable a => Proxy a -> IO () class Finalizable a -- things that are boxes around primitive data

3 5

RE: ForeignPtr
by Simon Marlow 08 Nov '02

08 Nov '02

> Ah, got you. > > How about making ForeignPtr slightly more polymorphic so that > instead of > working only on 'Ptr a' it works on 'a'. > > e.g., We'd have: > > newForeignPtr :: a -> Finalizer a -> IO ForeignThing a Hmm, interesting. This allows the implementation to divorce the object you're interested in finalizing from the object which the finalizer actually watches. eg. data ForeignThing a = ForeignThing a X where X is some object with "identity", i.e. an object which is only explicitly allocated in the IO monad. Examples are IORef, MVar, ForeignPtr - it doesn't really matter, as long as you can attach a finalizer to it and it can't be arbitrary duplicated by the compiler. In GHC, this means we could get rid of the ForeignObj# primitive type. If you want finalizer ordering, as discussed previously, the implementation would have to be data ForeignThing a = ForeignThing a !(IORef [Finalizer a]) (the IORef has identity, so that serves as our X). > obviously, we'd want to remove the word 'Ptr' from the name > of the type. > Candidates: > > ForeignProxy, ForeignObj, Foreign > > I think 'Foreign' is an essential part (at least, given the > restriction to C finalizers) and I favour the first two over the last > which seems too general. Maybe "Finalized"? Cheers, Simon

2 1