My statements refer not to the FFI, but as I said, to "FFI code". FFI-
based libraries seldom compile without excessive amounts of work,
they're often poorly documented, and in general they seem to be
maintained much less than pure Haskell libraries. The FFI is
necessary, of course, but in general I view it as a bootstrapping
process leading to pure Haskell libraries -- a crutch you have to live
with until you can afford to pay the price of walking.
Regards,
John
On Jan 8, 2009, at 3:15 PM, John Goerzen wrote:
On Thu, Jan 08, 2009 at 11:14:18AM -0700, John A. De Goes wrote:
But really, what's the point? FFI code is fragile, often uncompilable
and unsupported, and doesn't observe the idioms of Haskell nor take
advantage of its powerful language features. Rather than coding
through
That is an extraordinarily cruel, and inaccurate, sweep of FFI.
I've worked with C bindings to several high-level languages, and I
must say that I like FFI the best of any I've used. It's easy to use
correctly, stable, and solid. If anything, it suffers from
under-documentation.
The whole point of FFI is to bring other languages into the Haskell
fold. So you can, say, talk to a database using its C library and
wind up putting the strongly-typed HaskellDB atop it. Or you can
write an MD5 algorithm in C and make it look like a regular Haskell
function.
You can indeed fit a square peg in a round hole, if you pound hard
enough. That doesn't mean it's a good thing to do.
And with that, I fully agree.
-- Joh
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
