External Core - my goal

Neil Mitchell ndmitchell at gmail.com
Fri Dec 28 07:50:01 EST 2007


> > 2) Compile all the associate libraries and modules to generate
> > separate GHC Core files for each. Convert each Core file to Yhc Core.
> > Link the Yhc Core files together.
> >
> Now that I've read this more carefully -- I think plan (2) is your
> best bet. In theory, you should be able to do (2) now, using the HEAD.
> In practice, I'm sure there are bugs in the API code that I just added
> (and I haven't tested multiple-module programs), so you should try it
> out and holler

Fantastic, will do that in a few days time.

> (1) has the problem that you would have to implement a demodulizer for
> Core -- I don't think this would be all that hard, but there would be
> some of the same issues that exist for demodulizing Haskell, and it
> would take time. Of course, a Haskell demodulizer, HAllinOne, already
> exists, so that could be used as a guide.

Demodulizing Core should be trivial compared to HAllinOne - but we can
leave that for the moment if the other route is closer.

> Compiling the Core for the libraries should be easy enough. The way
> I've been doing it for my purposes is by creating a list of all the
> library Haskell source filenames, and running them through
> compileToCore (because GHC's automatic dependency-finding won't take
> care of this for me for package modules.) The main tricky bit for me
> has been dealing with GHC primitives. There are a lot of them. I don't
> know whether Catch needs to know what the semantics of the primitives
> are, though.

Catch assumes if a primitive is given all non-_|_ arguments, it
returns a non-_|_ result but assumes nothing more. This should be
sufficient for most primitives. There is also a mechanism for
overriding the definition of certain primitives. I don't expect
primitives to be more than a days work, and I can ignore the vast
majority of them.



More information about the Glasgow-haskell-users mailing list