Quoth Tomasz Zielonka : ... | What I fear about the future of Haskell, is that we will have so many | libraries FFIying to C, that our programs will crash as often as | programs written in C. | | FFI is necessary, but IMO it shouldn't be used when it doesn't have | to be. I spent some time recently trying to make a trivial text analysis run fast enough to use it on large data sets. I eventually achieved a satisfactory result - twice as fast as simple awk and Python versions. Of course I used the FPS packed string library functions, and I spent a lot of time profiling. One thing I found that way, is that FPS.words iterates over the string byte by byte, in Haskell, but there's a function (breakSpace?) that calls C to find the next space - and it's a lot faster. On the other extreme, I have found it surprisingly painless to call OpenLDAP functions from Haskell, which means I don't have to write my own LDAP protocol in Haskell, but also SASL, SSL, GSSAPI and Kerberos. The effort to do that would be enormous and eventually misguided, not a good thing for Haskell programmers in any way. So -- well, I actually agree with you in principle, but I'm just thinking it depends a lot on when we decide we `have to' use FFI, and in the end the advantages will very often be too compelling. Even for basic data manipulation without Haskell overhead, like FPS. Donn Cave, donn@drizzle.com