Aha! So what you really want is a code generator! I suggest you take a look at C--. www.cminusminus.org (Check out the papers especially.) It's designed for exactly what Stix is designed for, only much, much better. There's a prototype implementation from Fermin Reig, and Norman Ramsey is working hard on another. (I'm ccing him.) Hmm. Maybe someone can write a C-- front end for GHC's code generator! Simon | -----Original Message----- | From: Mark Alexander Wotton [mailto:mwotton@cse.unsw.EDU.AU] | Sent: 03 February 2003 22:19 | To: Simon Peyton-Jones | Cc: glasgow-haskell-users@haskell.org | Subject: RE: Modifying GHC to accept external Styx code | | On Mon, 3 Feb 2003, Simon Peyton-Jones wrote: | | > | > | I want to use GHC as a backend for my experimental compiler. | > | I'm trying to modify it to accept styx code from my compiler, and I'm | > | having some trouble working out where I need to make changes. In | > truth, | > | GHC is more haskell code than I've ever seen before in one place, and | > I'm | > | a bit lost: can anyone suggest which modules I should become familiar | > with | > | and which I should leave alone? | > | > You don't say what 'styx code' is. My advice: either translate styx to | > Haskell, or to External Core. (Probably the latter.) GHC can read both | > of these in without modification. | > | > External Core is a typed lambda calculus. | | Yes, I know External Core: I'm using it as my input language. (GHC is my | frontend as well.) The optimisation algorithms I want to implement need | a lower-level language than Core, which is why I want to use Styx, the | native generation intermediate language. Abstract C is also an option, but | if I've got to hack GHC to get either of them going, I'd rather do it for | Styx. | | Mark | | -- | no-one takes up music to play their own instrument | -- Randy Hiatt, Chalkhills list |