Hi Tim, Since you've now checked in External Core, I thought I'd ask how close we are to my ideal use case of External Core. My goal is to use External Core with Catch (http://www-users.cs.york.ac.uk/~ndm/catch/). To be able to use GHC Core with Catch, it is necessary to be able to do one of two things: 1) Compile all the associate libraries and modules of a program to generate separate GHC Core files for each one. Link them together to make one GHC Core file. Convert this Core file to Yhc Core. 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. I have no need to put the resultant Core back through GHC. How easy is it to compile up the Core for various associate libraries? Writing a convertor from GHC Core to Yhc Core is trivial, provided there can be some in-memory representation of GHC Core as an algebraic data type. The Core linker is trivial. The GHC bits are what I will need advice on! The Yhc compiler has this integrated, so that simply passing --linkcore will do all the magic listed here. Perhaps GHC could do with such a flag, or have some kind of ghc-linkcore program which is a wrapper around the GHC API. Thanks Neil
On 12/26/07, Neil Mitchell
Hi Tim,
Since you've now checked in External Core, I thought I'd ask how close we are to my ideal use case of External Core. My goal is to use External Core with Catch (http://www-users.cs.york.ac.uk/~ndm/catch/).
Hi, Neil-- I'm in the middle of a birthday party so I'll respond to the rest of this later, but just a quick correction -- what I checked in isn't External Core, it's just, well, Internal Core -- compiling to Core using the API. Being able to read back in Core from an external file will take more effort, although I plan to work on it soon. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "Faith, faith is an island in the setting sun / But proof, yes, proof is the bottom line for everyone."--Paul Simon
Hi Tim
I'm in the middle of a birthday party so I'll respond to the rest of this later,
Enjoy :-)
but just a quick correction -- what I checked in isn't External Core, it's just, well, Internal Core -- compiling to Core using the API. Being able to read back in Core from an external file will take more effort, although I plan to work on it soon.
I don't care about the reading back in part, for this project. I can always convert Internal Core to Yhc Core, which does have a well defined external representation. I guess this makes plan 2 more attractive, with the difference of converting Internal Core to Yhc Core before writing out. Thanks Neil
On 12/26/07, Neil Mitchell
Hi Tim,
Since you've now checked in External Core, I thought I'd ask how close we are to my ideal use case of External Core. My goal is to use External Core with Catch (http://www-users.cs.york.ac.uk/~ndm/catch/).
To be able to use GHC Core with Catch, it is necessary to be able to do one of two things:
1) Compile all the associate libraries and modules of a program to generate separate GHC Core files for each one. Link them together to make one GHC Core file. Convert this Core file to Yhc Core.
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 (I'll also try to do some more comprehensive testing; we'll see who gets to it first). So it might be realistic for you to use this for your thesis -- I'd suggest you try it soon and make some kind of decision after a couple of iterations of bug-finding. (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.
I have no need to put the resultant Core back through GHC.
How easy is it to compile up the Core for various associate libraries? Writing a convertor from GHC Core to Yhc Core is trivial, provided there can be some in-memory representation of GHC Core as an algebraic data type. The Core linker is trivial. The GHC bits are what I will need advice on!
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. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "Would you be my clock if I promise not to hang you / Too close to the window or the picture of the pope? / I won't set you back and I won't push you forward / I just want to look in your face and see hope" -- Dom Leone
Hi
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. Thanks Neil
participants (2)
-
Neil Mitchell -
Tim Chevalier