[Haskell] [ANNOUNCE] yhc - York Haskell Compiler
simonmar at microsoft.com
Wed Nov 16 10:39:24 EST 2005
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
>> 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
More information about the Haskell