[Haskell] [ANNOUNCE] yhc - York Haskell Compiler

[Simon Peyton-Jones]

| I am aware of some experiments with alternative back-ends for ghc, but
I
| don't know of any work on a ghc back-end generating portable bytecode.
| A few years ago some work was done towards a ghc-hugs fusion, but in
the
| end hugs remained separate and the ghc people developed ghci.  Perhaps
| ghc and/or hugs developers can comment further?

GHCi does indeed generate byte code, but we have never gotten around to
trying to dump it into files and reload it.  That might be an
interesting project -- but it only gives a constant performance factor
over loading the source files in the first place, so it's not clear that
it's a major win.

GHC is available now as a Haskell library (just say "import GHC").  The
idea is to make it possible for people to import GHC, use it to parse
and typecheck the program, and then process the result in whatever way
they want.  The interface is still evolving, but that evolution will be
strongly guided by what people want. It's in the HEAD only at the
moment, not any released compiler, but I do encourage interested parties
to give it a whirl.

| So far as debugging back-ends for ghc are concerned, Robert Ennals and
| Simon PJ did a stop-and-look style debugger using speculative
evaluation
| which perhaps is still distributed?

It's still available in Rob's CVS branch, but definitely not supported.
The entire speculative evaluation thing was tremendously interesting and
provocative, but it was just a bit too complicated to fold into the main
GHC head.

As Simon mentioned, though, another thing we'd like to see done is to
modify GHCi so that it always does cost-centre profiling.  That way,
every thunk would record who built it, and that would give quite a
powerful jumping off point for building a quick-and-dirty debugger.
There'd be a perf cost, but the effect would be muffled by the fact that
GHCi is an interpreter anyway.  Anyone?

Simon