[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon May 12 15:57:38 1994 
Subject:news-relayFrom: pop@uucp.rabbit (pop) 
From:PP User 
Volume-ID:940513.03 

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.