Question

I’ve spent a couple of days developing a program in Haskell, while learning the language. Now I realize that I’ll need to call Arpack (a Fortran library) or Arpack++ (a C++ wrapper to Arpack) — I can’t find a good implementation of Lanczos method with Haskell bindings. Do any more experienced Haskell programers have an opinion of how difficult this would be?

I’ve been able to get “.so” (“shared object”) versions of libarpack and libarpack++ installed through Ubuntu’s repository, but I’m not sure that will suffice. I suspect I’m going to ultimately need to build Arpack++ from source code, which is possible, but I’m getting a lot of build errors, so it will take time. Is there any way to use just the “.so” files, without knowing exactly which version of the header files were used to generate them?

I’m considering using GreenCard, because it looks like the most well maintained Haskell/C bridge. I can’t find much documentation though, so I’m wondering whether it will support C++ too.

I’m also starting to wonder whether I should rewrite my program in Python, and use scipy to call Arpack, but I’ve already sunk a couple of days into writing Haskell. I really like Haskell too, so I’m hoping I can make this work. I guess my overall question is this: What would be involved in making this work with Haskell?

Thanks much.

Answer 1

ELF format is standard format of executables and shared libraries, so accessing the code in these compiled modules is only a matter of knowing function names. If I understand correctly, Fortran is interoperable with C. As a consequence, Fortran should be interoperable with any language which can use C bindings, including Haskell. FYI, you can find all names exported by a module (executable or shared object or simple object archive) using nm tool (it is usually available in all linux distros by default). This of course would work if the binary file was not “stripped”, but AFAIK it is not common practice.

However, Haskell cannot use C++ bindings in sane way, since C++ polymorphic features require name mangling, and the method of this name transformation is highly compiler-dependent. It is well-known problem which is not specific to Haskell. Of course, you could try to get a list of exported symbols from C++ shared object and then bind them using FFI, but… It isn’t worth it.

As dsign said, you can use Foreign Function Interface GHC feature to create bindings to foreign code. All you would require is library headers (and the library itself of course). In case of C language that would be header files (*.h), but since your library is written in Fortran, you have to find header files analogue in library sources, refere to this page to match Fortran and C types, and then use this information to write FFI bindings. It would be helpful first to write C bindings, i.e. write C header. Then you can even use automatic FFI binding programs like c2hs.

It maybe also helpful to look through C++ bindings. It is possible that it has the header file I’ve described above. If it has one, then writing FFI bindings will be no more difficult than writing them for any other library.

So, it is not entirely impossible, but it may require some thorough work. Writing bindings to scientific/pure computational libraries is way easier than writing them for some system library which does a lot of IO and keeps its own internal state, but since this library is written not in C… Well, it may be advisable to invest your time in easier alternatives. I cannot say anythin about scipy, I’ve never used it, but since Python as a language is much more simpler than Haskell, it may be good alternative.