Thomas DuBuisson wrote:
And note that we wouldn't need unsafePerformIO for the FFI if all programs were made in Haskell ;).
Perhaps that's true, though entirely unrealistic, in the application world. In the OS world you need access to machine registers and special instructions (CR3 anyone? CP15?) which isn't built into any language save assembly - for these FFI will always come in handy.
Also, Haskell continues to have an unfortunate lack of primitives suitable for casting types (ex: zero copy form a bytestring like entity to Word32s). In this realm FFI can outperform cleaner looking code that must rely on individual byte reads.
The FFI doesn't always require unsafePerformIO, it's just there for those cases where the foreign function is truly side-effecting (and therefore should be linked to with the type (...->IO A)) but we know it's safe/referentially-transparent to ignore those effects at some call site. You can link to foreign code without giving it an IO type. The zero-copy version of converting bytestrings is one example where the foreign function is pure, and therefore doesn't need to be linked to as IO. -- Live well, ~wren