[Haskell-cafe] ghci & ghc -> JS (Emscripten)

Luite Stegeman stegeman at gmail.com
Wed Jul 3 13:05:25 CEST 2013

On Wed, Jul 3, 2013 at 12:26 PM, B B <blackbox.dev.ml at gmail.com> wrote:

> 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:


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.


[1] Foreign import javascript example:
[2] GHCJS IO Layer: https://github.com/ghcjs/shims/blob/master/src/io.js
[3] Daniil Frumin's GSoC project:
[4] Diagrams library: http://projects.haskell.org/diagrams/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20130703/67083064/attachment.htm>

More information about the Haskell-Cafe mailing list