[Haskell] [ANNOUNCE] yhc - York Haskell Compiler

[Simon Marlow]

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