GHCi in the web browser

[apfelmus]

GHCi in the web browser

Imagine that you're drawing a picture in Haskell with the  diagrams package. Wouldn't it be awesome if you could just enter the expression into GHCi and it would draw the picture right there, like this?

And what about entering a function of type Double -> Double in the interpreter and immediately seeing a graph of it?

The goal of this proposal is to create a Haskell interpreter that is capable of displaying images, animations and even interactive programs.

For maximum adoption and reuse, the GUI of the new interactive interpreter is to be implemented as a HTML page in the web browser. The GUI communicates with a server that is responsible for evaluating Haskell expressions.

Project Scope

This endeavor should emphasize modularity and reuse. The first step would be to create a small JavaScript? object that represents a Haskell interpreter and supports functions like GHCi.load(uri) or GHCi.eval(expr) and to implement corresponding server code. For maximum modularity, the server should load source files from a URI. Since we are now in a HTML page, the server can return values in the form of arbitrary images, animations, hyperlinks and so on.

Implementing this is not entirely straightforward, but most of the difficult problems have probably already been solved by prior work, like Chris Done's  TryHaskell online interpreter and Péter Diviánszky's  activehs online courses.

Building on these simple yet powerful basics, the view opens up to a wide range of possible applications:

• A replacement for the local GHCi, by running the server locally. Since the server can load from arbitrary URIs, this already allows us to code collaboratively with [Etherpad].
• Integration with source code editors and IDEs like  TextMate. In particular, augment compilation error with hyperlinks that point back to the source file.
• Turn GHCi into an online service, using the SafeHaskell? extension.
• Implementation of a notebook model (like Mathematica) that goes beyond the linear command line model of the traditional GHCi.
• Integrate into documentation tools like Haddock or Brent Yorgey's  diagrams user guide, so that explanations and API documentation can now be enhanced with live examples.
• Building a multiple user environment for use in teaching. A single interpreter session can be shared across different clients, be made read-only, and so on.
• Displaying interactive values. So far, the display is limited to static values, possibly animated with JavaScript?. But what about interactive values that communicate back with the server to evaluate more Haskell functions? Conal Elliott's  tangible values are the right abstraction for this.
• ...

Of course, this list is just a taste of the possibilities and not everything can be implemented in one summer. Still, I'm sure that the end result will be fantastic and that the emphasis on modularity will enable the Haskell community to build more awesome things on top.

Interested Mentors

Heinrich Apfelmus

Interested Students

[gregweber]

This idea is already being worked on at Stanford by David Terei, although he is largely focused on the security aspect of it.  https://github.com/dterei/ghci-in-a-new-dress

It would be great to collaborate though. Luite Stegeman is going to release a related project called Wolfgang also.

[shakya]

I have worked with Haskell and loved the language. This is definitely a good project and I am sure it would bring a Value to the community.Currently I am a Computer Engineering undergraduate and am interested on being mentored on this project.

[phischu]

I would love to do it. Here is how I understand the project: 1. Design a protocol for the communication between the browser and a server. The browser sends a haskell expression to the server. The server evaluates it and sends the result back. The browser displays the result. It is very important that the way the user can specify Haskell expressions as well as the types of data the browser can display are extensible. 2. Implement it. Are we on the same page? How is this related to #1607?

[gregweber]

#1607 would allow for a more responsive remote ghci through the use of websockets. Otherwise this would just use AJAX.

I think the main goal in the description of this project is not widely useful to the Haskell community: most of the time we aren't dealing with sound, images, or mathematical functions. And if we are dealing with mathematical functions, Mathematica is always going to be nicer and Wolfram Alpha can be used. It wouldn't necessarily be a waste to have these capabilities, but the other aspects are much more important to make this project worthwhile for the community.

[serras]

I've created a proposal for this idea in  Google Docs. Is there any way I could get feedback on it?

[apfelmus]

@serras:

I have read your proposal, it looks fine to me. That said, it does feel a little messy to me, but that is mostly a question of language and structure.

@gregweber:

Oh, I thought that the images/etc. are the "only" useful part of the project. Which other aspects are you interested in?

Once we have HTML output replacing the Show class, I'm confident that people will come up with awesome ways to use it. (The mathematical functions are just an eye-catching example.) For instance, you can visualize key-value dictionaries like Data.Map, which is very useful for debugging them. Same goes for tables or graphs. And why not develop an SQL query in the REPL, testing it on the database and getting to see a nicely formatted and interactive table at every step? Heck, why not develop HTML snippets like Yesod formlets in the REPL as well? I am quite enchanted by the possibilities.

[gregweber]

It is just kind of hard to take this proposal seriously when it focuses on the eye-catching examples that are not generally useful. Enormous programs are be written that would never be able to use them once.

Things in the realm of IDE functionality, such as HTML pretty-printing would be generally useful.

[luite]

Here's an idea of what it might look like if you go for a notebook model:  Example 1  Example 2

thanks to apfelmus for the diagrams demo. this page is basically a direct import of the .lhs file with two imports (Wolfgang.Diagrams and Wolfgang.Interactive) added, which contain the "rich result type" instances for Diagram and Interactive.

[apfelmus]

@luite:

Wow, that looks great!

I'm tempted to write all my Haskell code in a web browser from now on. ;-) But I doubt that I really want to do this. That's where modularity comes in: a suitably designed compilation back-end can be used for both a local GHCi replacement and a collaborative notebook website. Not to mention that it allows for more experimentation. For instance, one can make the sliders more Haskelly by using Conal's tangible values. Another idea would be to simply attach a contextual slider to every numeric value in an expression.

[luite]

Replying to apfelmus:

@luite: Wow, that looks great! I'm tempted to write all my Haskell code in a web browser from now on. ;-) But I doubt that I really want to do this. That's where modularity comes in: a suitably designed compilation back-end can be used for both a local GHCi replacement and a collaborative notebook website.

Unfortunately modularity isn't one of my code's strong points, and it will take some time to make a full locally installable version. But I think the client side wouldn't need to be changed that much: You edit a literate Haskell module with expressions, you can just import your "real" modules and edit those with your own editor.

Not to mention that it allows for more experimentation. For instance, one can make the sliders more Haskelly by using Conal's tangible values. Another idea would be to simply attach a contextual slider to every numeric value in an expression.

The API for the user interface in the example is rather low-level, it's more or less a direct Haskell representation of the data structure that Javascript picks up to render the interfaces (results of my eval class have two types, the original Haskell type of the expression, and a client-side type that determines how the browser renders the result. Each client-side type is supported with some Javascript).

Since Wolfgang.Interactive is just another wiki page, users could extend/modify it, but I think a better approach would be to make another module/page for higher level functionality, that either just uses Wolfgang.Interactive itself, or generates the client-side gui data directly.

One major limitation for interactivity though is that the server is basically stateless: every request is an expression (String), with a module name. The result is self-contained and must be generated within two seconds (can contain extra data files like png images or sound files). A local version could use longer timeouts (or even no timeouts, just a "stop" button), but true interactivity would require some major modifications.

[luite]

Another small  Example, shows a bit of how the Eval class / EvalRes? type and defaulting work. Here an instance is defined for (Double -> Double -> Double), and it uses the "surfacePlot" client-side type. This type is picked up by some Javascript that draws a WebGL plot of the data (you can rotate the plot by dragging, or zoom in/out with shift+drag).

The expression is a function that can be defaulted to (Double -> Double -> Double), so it's automatically rendered using this instance. Any other page could import Wolfgang.FunctionPlots? and get this instance to render these functions this way (if there are multiple applicable instances for a function that can be defaulted in multiple ways, one is picked).

[gregweber]

 http://ipython.org/ipython-doc/rel-0.12/whatsnew/version0.12.html