RE: unsafePerformIO around FFI calls
> > That's a nice succinct way to describe it. Another way, which boils > > down to the same thing but which is a little more concrete, is to > > ask: > > > - Does the function's result depend only on the values of its > > arguments? > > I have two problems with this alternative test: > > 1) It is sometimes slightly stricter test than necessary. > >Consider a hypothetical pair of C functions > > Foo toFoo(int); > int fromFoo(Foo); > >which satisfy the property > > fromFoo(toFoo(x)) == x > >but such that the result of toFoo does not depend on its argument. >(Perhaps toFoo allocates some memory in which to stores its result >and returns a pointer to that memory.) > >The function's result does vary independently of its values so it >fails your test. > >But if toFoo/fromFoo are the only functions on Foo, then we could >obviously have implemented the same API in Haskell with the aid of >newtype so it passes my test. Ok, if we're going to nit pick :) When talking about equality you have to restrict that to "observable equivalence" in the context of whatever abstract types you're dealing with. If a function always returns observably equivalent results when given observably equivalent arguments, then it is "safe". For example, toFoo would not be safe if you can test for equality between pointers. But if all you can do is convert it back using fromFoo, then you're ok. > 2) It fails to recognise the fact that IO actions have side effects. Well, side effects are usually only visible in the IO monad so that's ok. In your free() example, the result is either () or _|_, so the function does depend on more than just the value of the argument. I think the definition holds (but only just). For example, we normally consider a function which uses some temporary allocation on the C heap as "safe" to use from unsafePerformIO. But its side effect is visible from the IO monad by inspecting the C heap pointer. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: unsafePerformIO around FFI calls
> That's a nice succinct way to describe it. Another way, which boils > down to the same thing but which is a little more concrete, is to > ask: > - Does the function's result depend only on the values of its > arguments? I have two problems with this alternative test: 1) It is sometimes slightly stricter test than necessary. Consider a hypothetical pair of C functions Foo toFoo(int); int fromFoo(Foo); which satisfy the property fromFoo(toFoo(x)) == x but such that the result of toFoo does not depend on its argument. (Perhaps toFoo allocates some memory in which to stores its result and returns a pointer to that memory.) The function's result does vary independently of its values so it fails your test. But if toFoo/fromFoo are the only functions on Foo, then we could obviously have implemented the same API in Haskell with the aid of newtype so it passes my test. 2) It fails to recognise the fact that IO actions have side effects. For example, the C library function 'free' always returns the same result (i.e., '()') but it's a bad idea to call free twice on the same argument. One could argue that the side effect is part of the result because IO actions return a modified world but only a long term functional programmer would think like that so it doesn't help the man in the street. (In fact, IIRC, the Concurrent Haskell semantics doesn't use the state-passing explanation so you don't even see side effects reflected as changes in the returned world state.) -- Alastair Reid [EMAIL PROTECTED] Reid Consulting (UK) Limited http://www.reid-consulting-uk.ltd.uk/alastair/ ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: unsafePerformIO around FFI calls
> Hal Daume <[EMAIL PROTECTED]> writes: > > I'm curious exactly what is "safe" and what is "unsafe" to wrap > > unsafePerformIO around when it comes to FFI calls. > > Here's a simple test: > > Could you imagine an alternative implementation of the same API in > pure Haskell? (Don't consider efficiency or effort required to write > the implementation, just whether it can be done.) > > If so, then it is ok to use unsafePerformIO and the ffi to implement > the API instead. > > If it fails that test, it is incredibly unlikely that it is ok and a > proof that it is ok is likely to be pretty complex - maybe worth a > PLDI paper or some such. That's a nice succinct way to describe it. Another way, which boils down to the same thing but which is a little more concrete, is to ask: - Does the function's result depend only on the values of its arguments? (obviously only makes sense for a top-level IO function which you want to wrap in unsafePerformIO - for a non-top-level function or expression just replace 'arguments' with 'arguments and free variables'). Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: unsafePerformIO around FFI calls
Hal Daume <[EMAIL PROTECTED]> writes: > I'm curious exactly what is "safe" and what is "unsafe" to wrap > unsafePerformIO around when it comes to FFI calls. Here's a simple test: Could you imagine an alternative implementation of the same API in pure Haskell? (Don't consider efficiency or effort required to write the implementation, just whether it can be done.) If so, then it is ok to use unsafePerformIO and the ffi to implement the API instead. If it fails that test, it is incredibly unlikely that it is ok and a proof that it is ok is likely to be pretty complex - maybe worth a PLDI paper or some such. -- Alastair Reid [EMAIL PROTECTED] Reid Consulting (UK) Limited http://www.reid-consulting-uk.ltd.uk/alastair/ ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
unsafePerformIO around FFI calls
I'm curious exactly what is "safe" and what is "unsafe" to wrap unsafePerformIO around when it comes to FFI calls. If there's a general discussion of this somewhere and someone could send me a pointer that would be another acceptable solution. I googled for "unsafePerformIO FFI" but nothing relevant turned up. Anyway, here's the issue at hand. I have a function which takes a value and an IO action, allocates some memory, put the value in there, executes the IO action (which is an FFI function), gets the result, deallocates the memory and then returns the rest. For instance, we have an FFI function from LAPack which computes, say, eigenvalues. Because this is from fortran and in fortran everything is by reference, the function is an IO action of (simplified) type: > maxEigenvalue :: HMatrix -> IO Double implemented using FFI. We also have the CPS function to make the HMatrix: > withMatrix :: [[Double]] -> (HMatrix -> IO Double) -> IO Double which looks basically like (I'm on vacation so I don't have the real code right now): > withHMatrix m action = > do memory <- allocate memory >hm <- write m into memory >result <- action hm >deallocate memory >return result (it's slightly more complex because i need to make it safe in the case that action throws an exception and the memory is still deallocated before the exception is re-raised.) i can then wrap these together and say: > compEig :: [[Double]] -> IO Double > compEig m = withHMatrix m maxEigenvalue so the question is: Under what circumstances is it safe to make instead: > compEig' :: [[Double]] -> Double > compEig' m = unsafePerformIO $ withHMatrix m maxEigenvalue ??? Thanks! - Hal p.s., Please continue to CC Carl as this issue came up in conversations with him -- Hal Daume III "Computer science is no more about computers| [EMAIL PROTECTED] than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
