[Haskell-beginners] How Haskell Fits Into an Operating System / API Environment

Magnus Therning magnus at therning.org
Sat Aug 10 22:06:02 CEST 2013


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 at therning.org   jabber: magnus at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 230 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/beginners/attachments/20130810/309c4a2c/attachment.pgp>


More information about the Beginners mailing list