> 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 _______________________________________________ Glasgow-haskell-users mailing list [email protected] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
