ghcLiVE project escapes!

The final project is up! With many thanks to Luite Stegeman, my mentor for months of help!

And thanks to Darius Bacon and Edward Kmett for help in the last few days!

And Heinrich Apfelmus who helped get the interpreter infrastructure working.

It’ll be on hackage soon but in the meantime go grab the source and install it from github!

If you’re not yet convinced, check out this lovely screenshot of output from the diagrams library.

 

Please file any bugs found on the bug tracker, or contact me directly.

 

June Update

Mid-term evaluation is approaching, what’s the status of ghclive?

So far I’ve written four prototypes demonstrating various pieces.

• hintdownloadexecute adds code downloading to the demo that comes with hint.
• scottywebexecute add code execution to a demo that comes with the scotty web server.
• scottyjsonclock was a quick refresher for how AJAX works in Haskell.
• hintpostexecute uses all the previous prototypes together to give a very basic ghci in the browser, with the Main.hs module being loaded from any http URL.
• jqueryconsole extends the above prototypes to use Chris Done‘s jquery-console as famously seen in tryhaskell.org, giving a more GHCi-like result.

The end goal is still a collaborative shared source code editor and ghci on a single web page, with some extensions. I’d like to turn the jqueryconsole prototype into a cabal package to have on hackage right around midterm. Which leads us to the questions.

How should IO be handled?

Reading and writing to local files will work normally, but what about getLine and putStrLn? Should those have ‘web enabled’ versions that get or send text output to the browser?

I’d certainly like that, but how to do that without writing a modified Prelude?

What’s up with typeclass instance defaulting?

While (show . read) typechecks just fine, as types show below, the code still won’t do what you expect (unless you expect () ). Which typeclass instance should it choose? There’s not enough information.

show :: Show a => a -> String
read :: Read a => String -> a
(show.read) :: String -> String

This is also true for a typeclass like ToHTML where you have a function that produces a concrete HTML type result.

GHCi has built-in typeclass defaulting, and chooses () as the instance to read, but that won’t work for richer types like ToHTML. The standard fix is to add type annotations one way or another.

Luite has a concrete working (failing) demonstration of this problem. He also has a low level hack that uses the ghc-api to randomly choose a typeclass instance that will typecheck. Is there a better approach?

How to deal with signal handlers getting eaten by ghc-api?

If you’ve used ghc-api directly or through hint, you’ve noticed that ^C is no longer a UserInterrupt you can catch. This is because the ghc-api still acts much like ghci would, and eats your signal handlers.

Carl Howells wrote save-and-restore handlers for snap, maybe that’s the best option?

What’s the best choice for a collaborative editing component?

Luite Stegeman and I have had several discussions on which in-browser collaborative code editing component is the best choice.

So far it looks like CodeMirror, because it already has Haskell syntax highlighting and several people have hacked it into a collaborative widget.

Do you have any other suggestions for a collaborative in-browser code editing widget?

Props

Much appreciation to my mentor Apfelmus for the helpful weekly meetings and Luite for lots of discussion on IRC!

What should we put in the server component?

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:

1. 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.
2. 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.
3. 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.

A multi-user browser-based interactive ghci

Dear Haskellers,

this is the blog for the Google Summer of Code 2012 project “A multi-user browser-based interactive ghci”.

Student: Shae Erisson (shapr)
Mentor: Heinrich Apfelmus

The primary goal of this project is to create an interactive Haskell interpreter that lives in the web browser and allows users to share code and have simulatenous interpreter sessions, thereby facilitating the teaching and learning of Haskell. The idea is that in a not too far future, a typical conversation on the Haskell IRC channel may look like this:

Newbie: “Hey, I got a problem with my code here.”
Expert: “Sure, fire up the magic interpreter and we’ll check it out together.”
Newbie *shares link*
Expert: “So, where is the problem?”
Newbie *evaluates expression*
Newbie: “See, it has a type error here.”
Expert: “Hm. Ah, I see. You have to use a prehistomorphic zygomorphism.”
Expert *changes code and reloads*
Newbie: “Oh, it works! But how did you do that?”
Expert: “Well, it’s probably easier to understand if I write it like this.”
Expert *simplifies code*
etc.

The secondary goal of this project is to explore some of the possibilities of HTML output for a Haskell interpreter.