My approach to implementing Haskell is rather different to Steve's. Namely
I used the Glasgow Haskell Compiler (GHC) which normally generates C code,
and set switches to suppress the generation of C and instead to print out
STG code. The port was then a matter of implementing STG, which is a much
easier task since it is a simple "flattened" lambda calculus with case
expressions. The advantage of this approach is that most of the work Steve
refers to is done by the GHC - type checking, optimisation etc.. Moreover
improvements to the GHC are (almost) automatically incorporated.
This plan of course makes use of the GHC as an -external process- which POP
communicates with down pipes. However, since GHC is written in Haskell,
once the port is complete it can be run thro' itself. Some work would be
required to use the -internal- STG data-structures for code-generation,
but that should be straightforward. After which a fully native POPLOG GHC
would exist.
Some mods to the GHC were required to make the STG output sufficiently
complete to be used. It was really intended for debugging the compiler
itself. For example a specification of the alternatives for a data-type
had to be output.
For an undergraduate project, I think this route would be MUCH less
daunting, and much more likely to lead to something of permanent utility.
The advantages of haskell-in-poplog over the standard GHC would be (a)
incremental modification of programs on a compile-a-module basis. (b) Mixed
language working including all the X-based stuff.
Robin.
|