<div dir="ltr">On Wed, Jul 3, 2013 at 12:26 PM, B B <span dir="ltr"><<a href="mailto:blackbox.dev.ml@gmail.com" target="_blank">blackbox.dev.ml@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Thank you for your response :)<div>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?</div>
</div></blockquote><div><br></div><div style>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] ).</div>
<div style><br></div><div style>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.</div>
<div style> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">
<div>Is GHCJS "production ready"? Also - Can I use GHCJS to compile big projects (like GHC or GHCI) to Javascript?</div><div><br></div></div></blockquote><div><br></div><div style>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div></div><div>When you mentioned the file sizes I thought it would be good to further introduce what we are trying to do. </div>
<div>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.</div>
</div></blockquote><div><br></div><div style>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.</div>
<div style><br></div><div style>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)</div>
<div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">
<div>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.</div>
</div></blockquote><div><br></div><div style>I have a very crude example of this type here:</div><div><br></div><div><a href="http://hdiff.luite.com/reduce/">http://hdiff.luite.com/reduce/</a><br></div><div><br></div><div style>
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.</div>
<div style><br></div><div style>When we have the SELinux sandbox working, I plan to work on this again, so that users can enter/compile their own code.</div><div style><br></div><div style>luite</div><div style><br></div>
<div style>[1] Foreign import javascript example: <a href="https://github.com/ghcjs/ghcjs-jquery/blob/03b71effaeb059c9847306c93d69839588354134/JavaScript/JQuery/Internal.hs#L119">https://github.com/ghcjs/ghcjs-jquery/blob/03b71effaeb059c9847306c93d69839588354134/JavaScript/JQuery/Internal.hs#L119</a></div>
<div style>[2] GHCJS IO Layer: <a href="https://github.com/ghcjs/shims/blob/master/src/io.js">https://github.com/ghcjs/shims/blob/master/src/io.js</a></div><div style>[3] Daniil Frumin's GSoC project: <a href="https://github.com/co-dan/interactive-diagrams">https://github.com/co-dan/interactive-diagrams</a></div>
<div style>[4] Diagrams library: <a href="http://projects.haskell.org/diagrams/">http://projects.haskell.org/diagrams/</a></div></div></div></div>