Bundle an interpreter back-end with the front-end application

Proposal

At the moment, people who wish to install HyperHaskell have to install two things:

1. The graphical front-end application
2. A Haskell development environment (GHC + Cabal/Stack + some packages from Hackage)

For experienced users, this is the right approach, because they usually already have a Haskell environment (2) installed, and HyperHaskell should be compatible with it.

However, for absolute beginners, it is probably much more convenient to only install

1. The graphical front-end application, bundled with a smallish default Haskell development environment.

The idea is that experienced users can still opt to install their own environment (2) and use it with HyperHaskell, but beginners have an easier time getting started if the front-end includes a default environment that does not have to be installed separately.

Implementation

To implement the proposal, we have to bundle the following items with the application bundle

• The hyper-haskell-server executable
• A GHC package data base that includes the hyper package

and add a new option "default" to the "Settings" pane of a worksheet. When the user chooses "default", then this bundled package database will be used for evaluating worksheet expressions. If the user chooses any other option ("cabal" or "stack"), then the already established procedure for that option applies, and the bundled package database is ignored.

Adding the "Settings" option is not difficult, but unfortunately, there is a problem with bundling: The executable and package database need to be relocatable, because, in general, people are free to move the front-end application bundle around, there is no fixed location at which it is installed. The problem is that at the time of this writing, Cabal does not fully support relocatable package databases.

Cabal has some preliminary support for relocatable packages, but it's not enough. It seems to work for cabal sandboxes

The GHC for MacOS X project has managed to make at least those packages relocatable that are shipped with GHC. Essentially, it does so by manually overwriting the paths in the package.conf.d database. This may possible for a selected set of packages, but I'm not sure how it interacts with dynamic linking, external C libraries, data-file, or executables. Preliminary experiments suggest that it's not straightforward.

I guess that Haskell for Mac found a (partial) solution to this problem already, but being a proprietary product, I'm not sure if they are willing to share their approach.