On 15 November 2005 10:37, Lennart Augustsson wrote:

Simon Peyton-Jones wrote:

...

...

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.

The major win with having the byte code in a file is that you could have a stand alone byte code interpreter (and runtime system). That would make bootstrapping GHC a much less daunting task.

This would be nice, but for a couple of reasons it isn't entirely straightforward to do. - our byte code doesn't include primitives, because we rely on the base package always being compiled. If we were to interpret the base package, then we have to implement 200+ primitives in the byte code. Maybe we could cleverly map them to FFI calls and auto-generate the C implementations, or something. - to get portable byte code, the original Haskell code has to be platform-independent. Lots of Haskell code in GHC and the base package has #ifdefs. There was a thread a few months back on glasgow-haskell-users in which we counted the #ifdefs with a view to improving portability, you might want to look it up. The upshot was that the vast majority of #ifdefs were Windows-vs-Unix, so restricting portability to just Unix would be much easier than complete platform-independence. Cheers, Simon