September 2001 - Glasgow-haskell-users

Ptr and ForeignPtr Questions
by Ashley Yakeley 20 Sep '01

20 Sep '01

The documentation for FFI in the GHC user's guide seems to be out of date with regard to passing Ptrs across. 1. My reference is <http://www.haskell.org/ghc/docs/latest/set/ffi.html> (from <http://www.haskell.org/ghc/docs/latest/set/book-users-guide.html>) Is this the latest documentation available? 2. My understanding is that you can use any instance of 'Storable a => Ptr a' as an FFI argument and return type for both imported and exported functions? Is this correct? What if the type is polymorphic (e.g. declared as 'Storable a => Ptr a' rather than something like 'Ptr Word8')? 3. What about ForeignPtr? Can instances of 'Storable a => ForeignPtr a' be used in FFI? 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? -- Ashley Yakeley, Seattle WA

2 1

Posix.runProcess
by George Russell 19 Sep '01

19 Sep '01

I think Posix.runProcess should give access to the eventual exit state of the process, if any. Two possible ways: (1) Change its result to IO (IO ExitCode), the inner action being something that waits for the process to complete (without blocking all other threads!) and returns the ExitCode. (Even better would be to make the result just IO ExitCode but this might be too incompatible for people who rely on runProcess returning at once.) (2) If (1) can't be done, change its type to return something similar to Posix.getProcessStatus.

3 4

RE: unsafePtrCompare, anybody?
by Simon Marlow 19 Sep '01

19 Sep '01

> My intuition says that none of the side-effects in my > implementation are > visible from the abstract level of the module. However, the use of > unsafePerformIO certainly modifies the behaviour of the > module. For example, > the following definitions at the beginning of a GHCi session > on the attached > code lead to the subsequent behaviour: > > > foo1 <- return (unsafePerformIO (mkAtom "foo")) > foo2 <- return (unsafePerformIO (mkAtom "foo")) > bar <- return (unsafePerformIO (mkAtom "bar")) > safefoo1 <- mkAtom "foo" > safefoo2 <- mkAtom "foo" > safebar <- mkAtom "bar" > list <- return [safefoo1, safefoo2, safebar, foo1, foo2, bar] These uses of unsafePerformIO really *are* unsafe though :-) Your implementation of mkAtom seems to be similar the the StableName library, in that it has the property that if mkAtom e == mkAtom e', then e == e' but the reverse isn't necessarily true (it may or may not be true). Which is why mkAtom has to be in the IO monad: it has observable non-determinism. FastString works differently: it guarantees that both mkFastString s == mkFastString s' => s == s' s == s' => mkFastString s == mkFastString s' hold. So it is safe for mkFastString to be a pure non-I/O function, because it doesn't have any observable non-deterministic behaviour. Cheers, Simon

1 0

RE: unsafePtrCompare, anybody?
by Simon Marlow 18 Sep '01

18 Sep '01

> One's intuition would suggest that you could be safely > implement mkAtom > without wrapping it in a IO monad. After all, at least at a > abstract level, > an atom table is referentially transparent. The library > documentation says > that lack of side effects and environmental independance is > sufficent to > order for uses of unsafePerformIO to be safe. Is there a > exact (or at least > better) criterion for safety? An exact criterion would require a formal semantics for Haskell, which we don't have. But informally, if a function which is implemented using unsafePerformIO is pure - that is, its result depends only on the values of its arguments and possibly its free variables - then that is a "safe" use of unsafePerformIO. > "unsafePerformIO" is used in the implementation of > mkFastString, so how is it's side effects "safe". It is safe because the side effects aren't visible outside the implementation of mkFastString. HTH, Simon

3 2

RE: unsafePtrCompare, anybody?
by Simon Marlow 18 Sep '01

18 Sep '01

> I'm writing an atom table for a compiler/interpreter, and it > would be really > nice to use unsafePtrLT to implement tree-based finite maps. > > For clarification, my atom table consists of these three functions: > > mkAtom :: String -> IO Atom > show :: Atom -> String > (==) :: Atom -> Atom -> Bool > > such that > mkAtom s >>= (return . show) == return s > and > mkAtom . show == return > and > atom == atom' <=> show atom == show atom' > > mkAtom looks up each string in a table stored in an global > variable, and > returns the atom stored in the table if it is there. > Otherwise, it makes the > string into an atom, inserts the atom into the table, and > returns this new > atom. > > The point of all of this is that now string equality, when > strings are made > into atoms, is just pointer equality, which is available as > IOExts.unsafePtrEq. You might want to check out GHC's FastString module, which does essentially this. We use an explicit hash table, and each FastString has a unique Id for fast comparison. To solve your immediate problem, you could also take a look at the StableName library, which lets you map any old Haskell value on to an Int so you can build finite maps etc. (we use StableNames to build memo tables). There's a small garbage collector overhead for this, though. > Of course, the misuses of unsafePtrEq aren't nearly as > heinous as those of > unsafePtrCompare. On the other hand, it might be next to > impossible to > effectively use unsafePtrCompare in cases that it isn't > completely safe to > use, whereas there are plently of situations where > unsafePtrEq is semi-safe > to use. I can't think of a way to use unsafePtrCompare safely :-) The relative ordering of objects isn't guaranteed to be stable under GC. Cheers, Simon

2 1

Re: unsafePtrCompare, anybody?
by cwitty＠newtonlabs.com 17 Sep '01

17 Sep '01

Leon Smith <lps(a)po.cwru.edu> writes: > However, in this situation, pointer comparison is simply an arbitrary total > order on the set of all atoms, which is all we need to implement finite maps > based on search trees. And of course, pointer comparisons are a much cheaper > operation that actual string comparison. You could just add an extra Int sequence number to your Atoms, and compare using that. Carl Witty

1 0

I WILL TEACH YOU TO HAVE SEX - MY CAN IS ON FOR YOU
by AnnaCam＠sexbot.com 17 Sep '01

17 Sep '01

Below is the result of your feedback form. It was submitted by ANNA (AnnaCam(a)sexbot.com) on Monday, September 17, 19101 at 15:22:13 --------------------------------------------------------------------------- message: Hello my friend My cam is always on for you.....for your sex I cannot forget all the words that you told me last saturday while my wet pussy was open for you. Now you can connect to my CAM directly from my home page http://www.freebox.com/livesex I will teach you how to do. I have a new software for that. You'll find me nude waiting you. Don't leave me alone without you Anna ---------------------------------------------------------------------------

1 0

Re: Converting [Word8] to CString
by Ashley Yakeley 16 Sep '01

16 Sep '01

At 2001-09-15 02:15, Marcin 'Qrczak' Kowalczyk wrote: >Fri, 14 Sep 2001 23:40:42 -0700, Ashley Yakeley <ashley(a)semantic.org> pisze: > >> I'm looking for a function that will convert a [Word8] byte-array >> to a CString (i.e. a C byte array) for the purposes of FFI. > >You can use newArray which allocates the C byte array using malloc >so it must be freed by free, and cast the resulting pointer from >Ptr Word8 to CString using castPtr. Thank you. I ended up doing this and simply using Ptr Word8 as the FFI type. Curiously, the GHC user's guide sec. 8.2.4.1 seems to suggest that Ptr types are illegal as arguments in foreign import function declarations. I think this is the source of my confusion. http://www.haskell.org/ghc/docs/latest/set/sec-primitive.html#SEC-PRIM-TYPE S -- Ashley Yakeley, Seattle WA

1 0

Re: unsafePtrCompare, anybody?
by Marcin 'Qrczak' Kowalczyk 15 Sep '01

15 Sep '01

Sat, 15 Sep 2001 15:11:02 -0400, Leon Smith <lps(a)po.cwru.edu> pisze: > The point of all of this is that now string equality, when strings > are made into atoms, is just pointer equality, which is available > as IOExts.unsafePtrEq. > > However, in this situation, pointer comparison is simply an > arbitrary total order on the set of all atoms, which is all we need > to implement finite maps based on search trees. The physical pointer order changes with garbage collection. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

unsafePtrCompare, anybody?
by Leon Smith 15 Sep '01

15 Sep '01

I'm writing an atom table for a compiler/interpreter, and it would be really nice to use unsafePtrLT to implement tree-based finite maps. For clarification, my atom table consists of these three functions: mkAtom :: String -> IO Atom show :: Atom -> String (==) :: Atom -> Atom -> Bool such that mkAtom s >>= (return . show) == return s and mkAtom . show == return and atom == atom' <=> show atom == show atom' mkAtom looks up each string in a table stored in an global variable, and returns the atom stored in the table if it is there. Otherwise, it makes the string into an atom, inserts the atom into the table, and returns this new atom. The point of all of this is that now string equality, when strings are made into atoms, is just pointer equality, which is available as IOExts.unsafePtrEq. However, in this situation, pointer comparison is simply an arbitrary total order on the set of all atoms, which is all we need to implement finite maps based on search trees. And of course, pointer comparisons are a much cheaper operation that actual string comparison. Of course, the misuses of unsafePtrEq aren't nearly as heinous as those of unsafePtrCompare. On the other hand, it might be next to impossible to effectively use unsafePtrCompare in cases that it isn't completely safe to use, whereas there are plently of situations where unsafePtrEq is semi-safe to use. best, leon

1 0