So, Shae wants to build a multi-user browser-based Haskell interpreter.

The big question is: how do we distribute the functionality between

a server in the cloud

the user’s local machine

and the web browser window?

For instance, one option is to have a server that performs the evaluation of Haskell expressions. The problem is that this necessarily restricts the language dialect that we can offer. In particular, a server has two main restrictions: security and resource usage.

It looks like we have four options:

A public cloud server that evaluates Haskell expressions. It can be used by anyone. Existing examples: lambdabot, TryHaskell. We have to deal with security and resource usage. The state of the art for security is to use a module whitelist and SafeHaskell. For resource usage, calculations will have a time limit and the interpreter has to be stateless, i.e. you can’t declare new variables at the prompt. A private cloud server that evaluates Haskell expressions. To use it, you first have to create an account. This way, we can offer basic persistence and we have restricted the audience to an extend that we don’t have to worry much about resource usage. Evaluation of Haskell expressions is done on a user’s local machine. However, the new thing is that a user can share his session and code with other people on the internet. Of course, he retains full control over what is being evaluated on his machine. This solution is much in the spirit of a multi-player game session, where one player’s client turns into a server. A public cloud server can be used for “match-making” and NAT tunneling.

After some discussion, we found the third option to be the most appealing: we can offer the full Haskell dialect. Sooner or later, learners will have questions about Haskell in its full glory (IO, file system, parallelism and concurrency, …) and then we would be back to using hpaste. Furthermore, the administrative and coding overhead for the server is somewhat reduced.

What does the Haskell community think? Do you think that this is a path worth pursuing? Let us know in the comments.

Note that we want to start with a prototype interpreter running on a local machine anyway. But we still have some time to decide in which direction we will take this.

I didn’t mention the fourth option yet, because that one is a little wacky.

4. A public cloud server compiles Haskell to JavaScript and sends the JS code to the browser window. This immediately solves both the security and the resource usage problems. Unfortunately, since GHC doesn’t support compilation to JavaScript yet, it still limits the Haskell dialect, though in a different fashion than SafeHaskell does. It would be possible to use the Utrecht Haskell Compiler with the JS backend, though.