How to reduce binary footprint when using Haskell package 'plugins'?

Question

I have implemented a simple-minded loader for haskell plugins to my Main.hs module. The only function I use right now is load from this site

Looking at my compiled application size shows me an over 53 MB executable on the x86 architecture. I understand that big parts of GHC are linked in (due to the haskell-source-to-binary-plugin feature) but this is overkill for my purposes.

Is there an officially sanctioned way to shave off the extra features and only keep (dyn-)load?

Unload

possible duplicate of Small Haskell program compiled with GHC into huge binary – Rimma

@DanielWagner -- creating a -dynamic application would have still referenced the huge shared libraries, so the deployment issue would not have changed. – Unload

Answer 1

Depends on the meaning of 'officially sanctioned'. plugins (formerly known as hs-plugins) was designed to be an all-encompassing solution, with code generation and dynamic loading features. It does not aim at minimality.

A less complex package is available under the name direct-plugins, which focuses on the dynamic loading of plugins. This package reads Haskell interface (.hi) files to obtain the actual types of symbols, so that type-safeness is possible, but an unsafe variant is also provided. Unfortunately direct-plugins is bitrotten and does not work (a.t.m.) with GHC v7.6.

At the lowest end of the spectrum there is the unix package which provides a dlopen/dlsym-like mechanism to get hold of symbols that are exported from shared libraries. A convenience layer is also provided to automatically close open libraries after processing with them has terminated. However the symbols are obtained as FFI Ptrs and are not Haskell-callable.

By searching the internet I discovered an abandoned package that seems to be operating at middle ground:

• loading of symbols with Haskell calling convention is provided
• dependencies and package/module hierarchy can be declared
• dependency environment is managed in a thread-safe way.

The original package is authored by Hampus Ram. I have only prepared it for the latest released GHC and did some very shallow testing. Here is the repository:

https://github.com/ggreif/dynamic-loader

The only missing part is type-safe symbol access (by a possibly configurable mechanism). Comments and patches welcome.

Unload

As of today all loading routines that return polymorphic results must be given an argument that is used to perform 'expectation checking' on the loaded symbol by some (open-ended) criteria. – Unload