[Haskell-cafe] FFI - Approaches to C/C++

[Donn Cave]

Quoth Casey Basichis <caseybasichis at gmail.com>,
...
> I am using several other C++ libraries for which there are no existing
> bindings and no Haskell alternative packages that are even remotely
> close.
> 
> Are you suggesting it would be better to write all my own FFI bindings
> for all the needed libraries?
> 
> Everything I read suggests that Haskells strengths are in
> transformation and that interaction is not its strong suit.

I've done it, for my own amusement - wrapped a C++ graphics toolkit
and used it to write a couple small applications.

Most of us would probably object to your transformation/interaction
evaluation as presented above ... but it depends on your motivations.

In my case, I simply wanted to use Haskell, and in fact I started
with a model like yours where the UI was simply written in C++.
There were some very cumbersome things about that arrangement though,
so I was happy to integrate Haskell into the UI as soon as it became
possible.  On the other hand ... I'd be lying if I said the Haskell
code is "cleaner", or really advantageous in any compelling way if
we're just talking about the UI.  It has its moments - Haskell is
always going to pull a few things off pretty well, in a UI or whatever -
but of course, this particular UI API is specifically more suited
to C++, than Haskell.  So given that one can write good, clean code
in C++, too, the question is whether Haskell is so vastly advantageous
for such applications that it compensates for the sketchy binding.
It isn't, I think.

Whereupon we come to your original question.  Personally, I would
just work with the model that's natural to your API.  If it's a
C++ OO 3D graphics library, then go OO, for the very same reasons
discussed above.  FP may in principle have all the virtues mentioned
in that article, and it's good to be on the lookout for ways you can
deploy some of that in a C++ program, but when it comes time to use
that OO API, it's what you've got.

	Donn