Choosing a practical functional language (WIP)

I initially picked OCaml for my commercial project because

  • it’s imperative
  • fast
  • number of promising libraries were already written in OCaml (it’s a security project)

OCaml turned out to be a poor choice. It’s a “better C” language.

OCaml Haskell
Has fast FFI Yes Yes
Preemptive MT No Yes
Build system? No Yes
QuickCheck No Yes
(Referential transparency) No Yes

Both OCaml & Haskell can interface C at the overhead similar to inline call.

OCaml lacks preemptive multi threading. It’s foreign calls would block runtime system. To make it work with rest of application polling should be used (say OCaml goes to a plugin) Both are ugly

OCaml build system is behind Cabal. It’s impossible to mix C sources and OCaml in one shared library for instance without writing a plugin for ocamlbuild (which in turn is poorly documented)

Imperative programming promised to be a good way to make shortcuts for fast implementation of my project. In long run its bad too. Because of that there is no QuickCheck for OCaml.

Lack of referential transparency renders refactoring not safe. Again, slows down development

Bonus. Oh, did I mention CircleCI provides continuous integration for Haskell (Cabal) out of the box? smile

How to get minor GHC version from custom Setup.hs

Haskell Cabal is an advanced build system which can produce self contained shared library with few lines.
It’s necessary to list GHC’s runtime system to be able to dlopen the library:

  ghc-options: -threaded
  extra-libraries: HSrts-ghc7.10.2

-threaded is there to use the FFI in a multi-threaded setting which is usually the case.

Name of the library produced by GHC changes from build to build (due to “hash” being attached?)

Shared libraries are commonly used as a plugins. Other naming convention can be implemented at a postBuild hook in custom Setup.hs e.g. by renaming the library.

The tricky part comes when we need to figure out that “hash”.

We could use mkSharedLibName of Distribution.Simple.BuildPaths but that uses System.Info.compilerVersion internally which does not report minor version of GHC (that’s by design)

To address that this quick workaround will suffice for me for now. Get GHC version from Cabal:

 Just loc <- findProgramOnSearchPath normal defaultProgramSearchPath (programName ghcProgram)
 Just (Version { versionBranch = [g,h,c] }) <- programFindVersion ghcProgram normal loc

And re-write mkSharedLibName using g,h,c instead of CompilerId which is left as an exercise blink

I wonder what that “hash”‘s all about…