- Glasgow-haskell-users

RE: Alternative Design for Finalisation
by Simon Marlow 21 Sep '01

21 Sep '01

> OK, you are saying that the ForeignObj# is a representation > of a 'Ptr a', > but in a way such that the compiler can't optimise away the > box. Is that > correct? Yes, that's right. > Could ForeignPtr be generalised so that its ForeignObj# could > represent any type, rather than just a Ptr? Unfortunately no. The ForeignObj# type is unlifted, which means it doesn't have _|_ as a possible value. The same restrictions as for unboxed types apply: you can't instantiate a polymorphic type variable with ForeignObj#, or indeed any primitive type. Cheers, Simon

1 0

Re: Ptr and ForeignPtr Questions
by Ashley Yakeley 21 Sep '01

21 Sep '01

At 2001-09-21 01:39, Manuel M. T. Chakravarty wrote: >That's ok. All I am saying is that the FFI doesn't ensure >any concistency between the Haskell and the C type. Well it can't can it? There's no type information in object-code symbols (unless you use C++ identifier mangling, which Haskell doesn't). -- Ashley Yakeley, Seattle WA

2 1

Re: Ptr and ForeignPtr Questions
by Ashley Yakeley 21 Sep '01

21 Sep '01

At 2001-09-20 19:32, Manuel M. T. Chakravarty wrote: >What I meant with the remark that you quote is that if you >would use > > foreign import foo :: Ptr Int -> IO Float > >with > > float foo (float *x) > { > return *x; > } > >the system will not complain, but your program may dump >core. What if the C looked like this: float foo (int *x) { return *x; } ...? -- Ashley Yakeley, Seattle WA

2 1

Re: Student Programming Projects
by Albert Lai 21 Sep '01

21 Sep '01

Consider goal-directed theorem prover (or proof checker). Two existing samples are in Lawrence Paulson's ML for the Working Programmer, and yours truly's http://www.cs.utoronto.ca/~trebla/fp/prover/index.html The advantage of mine is it illustrates monads. The advantage of Paulson's is it doesn't scare people with monads :) and it includes a substitution library (yet another monad, but shhh) for use in first-order logic.

1 0

Re: Ptr and ForeignPtr Questions
by Ashley Yakeley 21 Sep '01

21 Sep '01

At 2001-09-20 06:55, Manuel M. T. Chakravarty wrote: >The FFI does not ensure any type consistency between the >arguments to `Ptr'/`ForeignPtr' and the corresponding C >types. I've been using 'Ptr Word8' with newArray to pass lists of bytes to C functions. They appear as unsigned char arrays in the C function. Is this wrong, or not guaranteed? -- Ashley Yakeley, Seattle WA

2 1

RE: Alternative Design for Finalisation
by Ashley Yakeley 21 Sep '01

21 Sep '01

At 2001-09-20 04:56, Simon Marlow wrote: >ForeignPtrs are defined like this > > data ForeignPtr a = ForeignPtr ForeignObj# > >where ForeignObj# is a *boxed* address, it corresponds to a real heap >object. The heap object is primitive from the point of view of the >compiler - it can't be optimised away. So it works to attach a >finalizer to the ForeignObj# (but not to the ForeignPtr!). OK, you are saying that the ForeignObj# is a representation of a 'Ptr a', but in a way such that the compiler can't optimise away the box. Is that correct? Could ForeignPtr be generalised so that its ForeignObj# could represent any type, rather than just a Ptr? -- Ashley Yakeley, Seattle WA

1 0

Re: Ptr and ForeignPtr Questions
by Ashley Yakeley 20 Sep '01

20 Sep '01

At 2001-09-19 23:45, Manuel M. T. Chakravarty wrote: >> What if the type is polymorphic (e.g. >> declared as 'Storable a => Ptr a' rather than something like 'Ptr Word8')? > >Also possible, as the argument to `Ptr' is just dummy. What? What about 'withObject'? A Haskell 'Ptr a' is a C array-pointer of whatever corresponds to 'a'. I don't think the argument is dummy. Consider this: int foo (char selector,char* arg) { if (selector == 100) return reinterpret_cast<unsigned char*>(arg)[1]; if (selector == 200) return reinterpret_cast<unsigned short*>(arg)[1]; return 0; } foreign import "foo" foo :: Storable a => Word8 -> Ptr a -> IO Int32; a <- withObject ([1,2] :: [Word8]) (foo 100); b <- withObject ([3,4] :: [Word16]) (foo 200); Will this work as expected? I expect 'a' to be 2 and 'b' to be 4... >> 3. What about ForeignPtr? Can instances of 'Storable a => ForeignPtr a' >> be used in FFI? > >They can be passed to C, but you can't get them back. (The >storange manager wouldn't know what finaliser to attach.) OK. Are ForeignPtrs intelligible in the C function as pointers to the named type? >> 4. Does newForeignPtr work safely with null pointers, and will the >> finalizer get called? For instance: >> >> fp <- newForeignPtr nullPtr finalFunc; >> let {isNull = (foreignPtrToPtr fp) == nullPtr}; >> r <- withForeign fp (\p -> foo p); >> >> Will foo be passed nullPtr? Will finalFunc ever get called? Is my use, >> above, of foreignPtrToPtr safe, and will isNull be True? > >Should work. From the storage managers point of view, a >`Ptr' is just an uninterpreted bit-pattern. A glorified >`Int'. So you are saying that the ForeignPtr code is not interested in the "pointer-ness" of the Ptr contents of a ForeignPtr, except when a ForeignPtr is used as an FFI argument? Presumably this also means that one can create two separate ForeignPtrs around the same Ptr, each with their own finaliser set. Presumably they would not be equal (note that Eq (ForeignPtr a)). Is this correct? Also, I assume that a ForeignPtr is eligible for garbage collection whenever it is no longer 'reachable', even if the Ptr it contains is reachable. Is that correct? Is there anything resembling Java's 'soft' and 'weak references'? > Of course, you should better make sure that >`finalFunc' can handle getting a `nullPtr'. Of course... -- Ashley Yakeley, Seattle WA

2 1

RE: Alternative Design for Finalisation
by Simon Marlow 20 Sep '01

20 Sep '01

> Unfortunately it isn't possible to add a finalizer to a (Ptr a). We > already have a generic finalization mechanism: see the Weak module in > package lang. But the only reliable way to use finalizers(*) is to > attach one to an atomic heap object - that way the compiler's > optimiser > can't interfere with the lifetime of the object. I forgot the footnote: (*) sometimes it doesn't matter that the object being finalized might be optimised away or duplicated. For example, we use the notion of finalizers on arbitrary objects for our implementation of memo tables, which rely on pointer-equality (actually StableName equality). If an object gets optimised away or duplicated by the optimiser, then the memo table is just less effective. Cheers, Simon

1 0

RE: Alternative Design for Finalisation
by Simon Marlow 20 Sep '01

20 Sep '01

> If ForeignPtrs work the way I think they do, then I'm > surprised they're > designed as pointers. I believe the 'pointer' functionality > is orthogonal > to the 'finalisable' functionality and should be separated like this: > > -- > data Finalisable a -- abstract handle to finalisable object > instance Eq (Finalisable a); > newFinalisable :: a -> IO () -> IO (Finalisable a); > addFinaliser :: Finalisable a -> IO () -> IO (); > withFinalisable :: Finalisable a -> (a -> IO b) -> IO b; > touchFinalisable :: Finalisable a -> IO (); > finalisableContents :: Finalisable a -> a; > > type ForeignPtr a = Finalisable (Ptr a); > newForeignPtr :: Ptr a -> IO () -> IO (ForeignPtr a); > newForeignPtr = newFinalisable; > addForeignPtrFinalizer :: ForeignPtr a -> IO () -> IO () ; > addForeignPtrFinalizer = addFinaliser; > withForeignPtr :: ForeignPtr a -> (Ptr a -> IO b) -> IO b; > withForeignPtr = withFinalisable; > touchForeignPtr :: ForeignPtr a -> IO (); > touchForeignPtr = touchFinalisable; > foreignPtrToPtr :: ForeignPtr a -> Ptr a; > foreignPtrToPtr = finalisableContents; Unfortunately it isn't possible to add a finalizer to a (Ptr a). We already have a generic finalization mechanism: see the Weak module in package lang. But the only reliable way to use finalizers(*) is to attach one to an atomic heap object - that way the compiler's optimiser can't interfere with the lifetime of the object. The Ptr type is really just a boxed address - it's defined like data Ptr a = Ptr Addr# where Addr# is an unboxed native address (just a 32- or 64- bit word). Putting a finalizer on a Ptr is dangerous, because the compiler's optimiser might remove the box altogether. ForeignPtrs are defined like this data ForeignPtr a = ForeignPtr ForeignObj# where ForeignObj# is a *boxed* address, it corresponds to a real heap object. The heap object is primitive from the point of view of the compiler - it can't be optimised away. So it works to attach a finalizer to the ForeignObj# (but not to the ForeignPtr!). There are several primitive objects to which we can attach finalizers: MVar#, MutVar#, ByteArray#, etc. We have special functions for some of these: eg. MVar.addMVarFinalizer. So a nicer interface might be something like class Finalizable a where addFinalizer :: a -> IO () -> IO () instance Finalizable (ForeignPtr a) where ... instance Finalizable (MVar a) where ... (apologies for the different spelling of finalize - apparently both are correct and I randomly settled on the 'z' version some time ago). So you might ask why we don't just get rid of Ptr and rename ForeignPtr to Ptr. The reason for that is just efficiency, I think. > The only time when ForeignPtrs act like Ptrs is when they are > used as FFI > arguments. But I believe that's purely syntactic sugar for > withForeignPtr, and would be no loss. Indeed, the latest version of the FFI spec dissallows ForeignPtrs as FFI arguments. Hope this all makes some sense. I'll copy the text into the GHC commentary if so. Cheers, Simon

1 0

Alternative Design for Finalisation
by Ashley Yakeley 20 Sep '01

20 Sep '01

If ForeignPtrs work the way I think they do, then I'm surprised they're designed as pointers. I believe the 'pointer' functionality is orthogonal to the 'finalisable' functionality and should be separated like this: -- data Finalisable a -- abstract handle to finalisable object instance Eq (Finalisable a); newFinalisable :: a -> IO () -> IO (Finalisable a); addFinaliser :: Finalisable a -> IO () -> IO (); withFinalisable :: Finalisable a -> (a -> IO b) -> IO b; touchFinalisable :: Finalisable a -> IO (); finalisableContents :: Finalisable a -> a; type ForeignPtr a = Finalisable (Ptr a); newForeignPtr :: Ptr a -> IO () -> IO (ForeignPtr a); newForeignPtr = newFinalisable; addForeignPtrFinalizer :: ForeignPtr a -> IO () -> IO () ; addForeignPtrFinalizer = addFinaliser; withForeignPtr :: ForeignPtr a -> (Ptr a -> IO b) -> IO b; withForeignPtr = withFinalisable; touchForeignPtr :: ForeignPtr a -> IO (); touchForeignPtr = touchFinalisable; foreignPtrToPtr :: ForeignPtr a -> Ptr a; foreignPtrToPtr = finalisableContents; -- I am slightly bothered by the type of finalisableContents/foreignPtrToPtr. Shouldn't it be in the IO monad? Apart from 'finalisers already run' risk, is it safe? But 'castForeignPtr' would not be definable, unless you wanted to do something like this: -- instance Functor Finalisable; castForeignPtr :: ForeignPtr a -> ForeignPtr b; castForeignPtr = fmap castPtr; -- ...which I don't believe is appropriate. The only time when ForeignPtrs act like Ptrs is when they are used as FFI arguments. But I believe that's purely syntactic sugar for withForeignPtr, and would be no loss. -- foreign import "foo" fooFP :: ForeignPtr a -> IO (); foreign import "foo" fooP :: Ptr a -> IO (); fooFP' :: ForeignPtr a -> IO (); fooFP' fp = withForeignPtr fp fooP; -- -- Ashley Yakeley, Seattle WA

1 0