UHC-like JavaScript backend in GHC

[Luite Stegeman]

> Does/can cabal-install support GHCJS? I suppose that's a minor advantage of extending GHC itself; you get cabal support almost for free.

Yes. There are two GHCJS installation options. One is the standalone
option that includes wrappers for cabal and ghc-pkg. You use
`ghcjs-cabal` to install packages, see the result with `ghcjs-pkg
list`. The standalone compiler can be installed with cabal-install,
but it does require you to run `ghcjs-boot` in a configured GHC source
tree, to install the core libraries (ghc-prim, base, integer-gmp).

The alternative is the integrated compiler, where you completely
replace your existing GHC with one that can output Javascript. You
don't get separate package databases this way.

> How big are the JS files generated with either the new or the old code generator? I recall there was a HS -> JS effort out there that generated huge JS files. UHC's output is relatively compact and doesn't grow as fast with bigger programs.

Relatively big for the new generator because I haven't focused on this
yet. The generated code has lots of redundant assignments that can be
weeded out later with a dataflow analysis pass. The old generator is a
bit more compact (similar to haste compiler). Both versions have a
function-level linker that only includes functions that are actually
used.

> WebWorkers is quite limited indeed. I'm not yet sure how the serialisation might complicate matters, but it seems that WebWorkers is only really a possible backend for `fork`, and not `forkIO`.

For one, you cannot serialize closures, so it will probably be similar
to the restrictions in Cloud Haskell in that you can only call
top-level things on the other side (Unless you don't use Javascript
closures for your Haskell closures, the new GHCJS generator can
actually move closures to a WebWorker, at least in theory, it's not
yet implemented)

luite