On Wed, Jul 3, 2013 at 6:26 AM, B B
Could you please answer one additional question - why you, while creating GHCJS didn't base on emscripten? Why haven't you patched it and created custom solution?
I'd like to point out that the LLVM code from GHC is CPS-transformed, and this makes it a nightmare to work with. Already the LLVM optimizer pretty much fails to do anything: optimizing CPS-transformed code is well-nigh impossible without knowing what the pre-transformation code was, which means a GHC-specific optimizer is necessary, or some way to communicate the code's structure (LLVM actually supports annotations for this, but current GHC doesn't generate them; I also would expect those annotations to go only so far without GHC-specific tweaks to LLVM, and in fact I am under the impression such tweaks have been proposed for inclusion in LLVM). Similarly I would expect that generating any sort of sensible Javascript would require something fairly tightly tied to GHC; otherwise the output's going to have horrible performance because it's not going to understand the input and will fall back to the slowest but most general translation. (If it even has such a fallback, instead of simply failing on code that it doesn't recognize.) -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net