Feedback on Haskell FFI [closed]

Question

I am new to functional programming (a C++ / C# programmer mostly) and I am about to start a new project. There are no strict deadlines, and at this point there are no restrictions on which technologies can be used.

The core of the project is to parse (relatively) large CSV files and to populate Excel and Word templates. I am considering two approaches, Qt/C++ - Haskell doing the CSV parsing, calculations and such, and C# for UI with F# doing the heavy lifting. I want to start with C++/ Haskell since it is more challenging.

My primary concerns are FFI and state in Haskell. How robust is Haskell FFI for passing large arrays of structures and C callbacks? Do I use the State monad to retain the large data set in memory between the function calls into the Haskell DLL? I am new to Haskell :)

Answer 1

How robust is Haskell FFI for passing large arrays of structures?

Everything must be marshalled/unmarshalled at the language barrier. It's common to make large data structures be opaque to one language or the other. That is, if there's a large C data structure, simply keep a pointer to it in Haskell-land and import C functions that do the operations you need; likewise, if there's a large Haskell data structure, expose the Haskell functions that munge it to C-land.

How robust is Haskell FFI for C callbacks?

It is easy and common to turn Haskell closures into C-style function pointers.

Do I use the State monad to retain the large data set in memory between the function calls into the Haskell DLL?

This depends a lot on the API you design. In many cases (e.g. most UI libraries) this is not really feasible, because the main loop is in C, not Haskell; one instead uses IORef or similar.

That said: if this is your first Haskell project, I strongly recommend avoiding manual FFI efforts, especially making an attempt to mix Haskell and C++ via the FFI. There's plenty of difficult stuff to get accustomed to without throwing that into the mix. If the only thing you were planning to use it for was UI, then take advantage of others' hard work: there are Haskell bindings to the biggest UI toolkits available on Hackage.

Answer 2

Learning Haskell is a great way to become a good functional programmer as it teaches you how to write code in a purely functional way - which is something that other functional languages emphasize too, but they do not force you to do it.

That said, if you want to interoperate with something like Excel (which is inherently a mutable imperative API), then using a language that does not force you to be pure might be an easier way to approach the problem.

Most of the people writing code for Excel these days are using .NET and so the .NET libraries for Excel (which work nicely from F#) are much more advanced than what you'd get in any other platform.

You might want to look at the following libraries before deciding:

• NetOffice is a very well documented library, wrapping all of the Office APIs in a (fairly) easy to use .NET API which you can use from F# without any impedance mismatch.

• Csv Type Provider which is a part of F# Data is not just a CSV parser, but it also infers the type based on your CSV file and gives you a typed access to the CSV data structures.

• If you want to do some data analysis, then Deedle is an open-source data analytics library for F# that has been developed by BlueMountain Capital and is very well tested - and has really simple API for doing basic data analysis on reasonably sized (but fairly big) data sets (you should be fine if it fits in 2GB)

Sounds like for the kind of project you are describing, you can really get a lot just by using the .NET/Mono libraries and F#-specific libraries that are already out there - and being on the same runtime, you do not have to worry about any FFI.