June Update

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

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

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?


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

This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s