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!
ghcLiVE 