ncm wrote: Haskell lacks the facilities to enable programmers to code and encapsulate resource management.
There's been some work done on the region management of state under the banner of monadic regions, and Google tells me that there's an implementation of the idea for ghc in the Hackage code repository, Ivan Tomic's IOR. I haven't looked at the details of that package, but in principle it allows you to manage certain explicitly declared state, which might be exactly what some programs need. It doesn't help you with managing the undeclared resources, part of Haskell's hairy runtime cost, so it doesn't make Haskell suitable for the kind of system programming that BitC is designed for.
Add the ability to parse C header files directly, and call functions declared
there, and most of your standard library collapses to trivial wrappers.
C++ pays and pays for it, but the great advantage C++ gains from simply
including almost all of C is that there's nothing foreign about interfacing to C.
In the
paper introducing c2hs, Manuel Chakravarty says:
SWIG works well for untyped scripting languages, such as Tcl, Python, Perl, and Scheme, or C-like languages, such as Java, but the problem with typed functional languages is that the information in the C header file is usually not sufficient for determining the interface on the functional-language side. As a result, additional information has to be included into the C header file, which leads to maintenance overhead when new versions of an interfaced C library appear.The two FFIs for Haskell, c2hs and Greencard, take opposite routes. Greencard, like SWIG, includes extra info in the header file, Greencard needing quite a bit more than SWIG, while c2hs provides an interface to allow Haskell wrapper code to be written to bridge the information hole, but of course that introduces another kind of maintenance overhead.
What you want doesn't seem to gel with Haskell.