stegeman at gmail.com
Tue Nov 13 20:53:37 CET 2012
> 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
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
> 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
closures for your Haskell closures, the new GHCJS generator can
actually move closures to a WebWorker, at least in theory, it's not
More information about the Glasgow-haskell-users