On Sat, Aug 10, 2013 at 10:22:06AM -0400, Philippe Sismondi wrote:
I am interested in tracking down discussions on how Haskell fits into an operating system environment. That is probably not a very clear question, so let me explain.
One of the great obstacles I have faced in using two of my favourite languages (Common Lisp and Haskell) for anything practical is that I am constantly frustrated by their relationship with the host OS, or perhaps more accurately with the APIs provided by the OS.
For example, I tend to program mostly on OS X. I have a reasonable knowledge of Cocoa, and can get quite a lot done with Objective-C. So, if I want to use Haskell on OS X, I can run off and learn about Haskell's FFI, or some hand-rolled widget package, etc. But here is the problem: Cocoa et al provide an entire ecosystem that includes data structures, error handling, and so on. So, when trying to use Haskell with a GUI, or perhaps to do some audio processing, or other things that are provided by the OS X APIs, I feel that I am layering two quite incompatible worlds together: Haskell and its host environment.
I ran into the same dilemma with Common Lisp. Clozure Common Lisp provides an excellent Cocoa binding. But using it feels (to me) like communications between alien races. The OS APIs want to do things the Objective-C way, and that is (clearly) not the Haskell or Lisp way.
I'm not sure there are a lot of discussions or texts on this issue, but maybe you can find some solace in me thinking that this problem pops up whenever one tries to combine components written in different languages. For instance C++ is able to call straight to C libraries, but that doesn't mean that C APIs fit well into "idiomatic C++" (or maybe I should say one of the many "idiomatic C++s"). The same goes for all other combinations I've tried out myself, Python+C, Python+C++, Java+C, Haskell+C... I'm fairly sure it is the case with *every* combination. I'm also fairly sure that the friction becomes higher the more different the languages are, i.e. combining two procedural (non-OO) languages is most likely easier than combining a procedural (non-OO) with an OO language, even if both are imperative. If the languages have different paradigms, e.g. imperative vs. functional, the friction becomes higher still.
One soon notices that books on Haskell pay virtually no attention to this issue. At least, the ones I have don't.
I believe the FFI is touched upon, but providing an idiomatic Haskell API for a C library is most likely an art (maybe a black one ;) at this point. So in short, you are right. (I'd love to be proven wrong here and be pointed to some recipe book for how to wrap C in Haskell, or C in Python, and do it well.) /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus I invented the term Object-Oriented, and I can tell you I did not have C++ in mind. -- Alan Kay