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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
