I don't see why it should be hard to use GHC's back end in this way. GHC's core language is pretty stable. I don't find the external representation of Core very appealing, but it's really meant for computers not people.
An important constraint is that Core is *typed*, so you'd need a front end that kept type information around. Best thing would be to try a small experiment, to climb the learning curve a bit. Compile some little programs with GHC and see what Core they produce. Try generating a little Core. And so on. Kirsten Chevalier has quite a bit of experience of producing External Core using GHC, transforming it externally, and stuffing it back into GHC. Simon | -----Original Message----- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Arjan van | IJzendoorn | Sent: 13 February 2004 12:43 | To: [EMAIL PROTECTED] | Subject: [Haskell] GHC Core & backend | | Hello all, | | Is anybody using GHC's backend as a backend for their own compiler? | | In the paper "An external representation for the GHC Core Language" the | introduction states that "there are many (undocumented) idiosyncracies in | the way GHC produces Core from source Haskell". And that "it will be hard to | produced Core that can be integrated with GHC-produced core, and we don't | aim to support this". Has this changed since the time of writing this paper? | | It would be cool if, let's say, Helium (http://www.cs.uu.nl/helium) could | use all of GHC's libraries... | | Regards, Arjan van IJzendoorn | | _______________________________________________ | Haskell mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/haskell _______________________________________________ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
