| 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