You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the moment, people who wish to install HyperHaskell have to install two things:
The graphical front-end application
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
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.
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.
The text was updated successfully, but these errors were encountered:
Stack can install both GHC and Haskell packages in a non-destructive way, so maybe an option could be to bundle Stack with HyperHaskell and then instruct the user to use stack to bootstrap the Haskell environment or include an installer that does this.
@Toxaris Essentially, this would correspond to embedding an installer into HyperHaskell that simply runs stack and displays the terminal output in a window. I like the idea. It's less convenient for the user than direct packaging, but it's also easier to implement.
Proposal
At the moment, people who wish to install HyperHaskell have to install two things:
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
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
hyper-haskell-server
executablehyper
packageand 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.
The text was updated successfully, but these errors were encountered: