On Wed, Jul 3, 2013 at 12:26 PM, B B
Thank you for your response :) 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 didn't know a good way to get the tail calling to work, and also it looked like it would be hard to make it as convenient to use as higher level JavaScript (we can just wrap JS objects in Haskell thunks, insert foreign imports directly in the functions (example: [1] ). That said, asm.js/emscripten have progressed a lot since I started working on this (I started on the 'gen2' code generator in August last year). Perhaps when JS gets native tail calls, it might be time to give LLVM/emscripten another look.
Is GHCJS "production ready"? Also - Can I use GHCJS to compile big projects (like GHC or GHCI) to Javascript?
I think GHCJS should be able to compile all Haskell code in GHC, but we haven't tested this yet. The tricky bit is probably getting foreign code work, and creating a working installation that includes all other things, like libraries and a package database. Usually, GHCi loads object files for the libraries when running Haskell code. Obviously you can't run machine code with JavaScript, so you'd have to find a way around it. GHCJS includes an IO layer, which can be used to set up a virtual filesystem [2], but the API is far from finished.
When you mentioned the file sizes I thought it would be good to further introduce what we are trying to do. We want to be able to send a haskell code to a server to compile it and return the resulted JS to user as a compiled library. We want users to be able to connect these compiled functions together to get some interactive results.
Ah it's much easier if the code can be compiled on the server. This is more or less what Daniil Frumin is doing for his Google Summer of Code project [3]. We are using GHC on the server for non-interactive things, and GHCJS to compile interactive code that is run on the client. Our main goal is to get interactive graphics with the diagrams [4] library working. Currently he is working on building a good sandbox for the compiler on the server (With SELinux, rlimits and cgroups) so that we can compile code, and run Template Haskell safely. I'm working on improving the GHCJS linker, so that we can support incremental code loading more easily (so users can download just the code for the new function they wrote, instead of the whole program every time)
for example: user is creating 2 functions (pseudocode): a(x) and b(x). They are send to server and compiled to JS. Then in an online tool user is connecting (visually with lines) a data (lets say a list of ints) [] -> a -> b. While connecting it we want this tool to "interpret" such connections and visualise the data on each step - so we want to have some kind of "runtime" or "interpreter" on client side.
I have a very crude example of this type here: http://hdiff.luite.com/reduce/ It's hacked together in one day, replacing the GHCJS main loop with one that draws a graph of the stack and heap every reduction step. It could be much better obviously, with better forward backward stepping/tracing and more information about the objects, and of course improved presentation. When we have the SELinux sandbox working, I plan to work on this again, so that users can enter/compile their own code. luite [1] Foreign import javascript example: https://github.com/ghcjs/ghcjs-jquery/blob/03b71effaeb059c9847306c93d6983958... [2] GHCJS IO Layer: https://github.com/ghcjs/shims/blob/master/src/io.js [3] Daniil Frumin's GSoC project: https://github.com/co-dan/interactive-diagrams [4] Diagrams library: http://projects.haskell.org/diagrams/