Does anyone have any comments on the following criticism of some difficulties with FFI, including IO, in Haskell: http://groups.google.com/group/comp.lang.functional/msg/6d650c086b2c8a49?hl=... In particular, is it not always possible to write IO libraries safely in Haskell? -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e
Jon Harrop wrote:
Does anyone have any comments on the following criticism of some difficulties with FFI, including IO, in Haskell:
http://groups.google.com/group/comp.lang.functional/msg/6d650c086b2c8a49?hl=...
That post conflates two separate questions. 1) binding to foreign libraries that export functions that are semantically pure, but can't be imported as pure functions, for example because they use pointers. unsafePerformIO was added in the FFI spec for exactly this purpose, as you can see for yourself here: http://www.cse.unsw.edu.au/~chak/haskell/ffi/ffi/ffise5.html#x8-240005.1 2) global variables. This has been a topic of long and heated debates, with no clear winner. I don't think another debate will be fruitful.
In particular, is it not always possible to write IO libraries safely in Haskell?
Flame bait? Yes, it is not always possible, because some interfaces are inherently unsafe, putting the burden of using them safely on the user. unsafePerformIO itself is a prime example for this. Bertram
Hello Jon, Wednesday, April 22, 2009, 1:54:58 PM, you wrote:
Does anyone have any comments on the following criticism of some difficulties with FFI, including IO, in Haskell:
http://groups.google.com/group/comp.lang.functional/msg/6d650c086b2c8a49?hl=...
In particular, is it not always possible to write IO libraries safely in Haskell?
i think that this letter is true on factual part but he exaggerate this problem 1) you can develop any pure-haskell imperative library with safe (no global state) interface and implementation. well, you can do the same with any other language too :) 2) if you are going to hardware level, it usually has von Neumann architecture, i.e. global state. so when providing some service to application, you have to deal with global state at some level. if it doesn't handled at C level (in his example, MVar may be maintained at C side), you need to to this at Haskell level 3) haskell language still doesn't provide features to create global variables, although it was proposed to add syntax he uses: globalLock <- newMVar False -- the same as globalLock = unsafePerformIO (newMVar False) -- but with guarantees of no sharing so we use unsafePerformIO hack instead that's all. if we sometimes deal with global-state C libraries, we may need to use global vars too. anyway, at some level (be it C or Haskell) we need to create safe interface too unsafe von Neumann hardware -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
participants (3)
-
Bertram Felgenhauer -
Bulat Ziganshin -
Jon Harrop