On 2/20/08, Roman Leshchinskiy <[EMAIL PROTECTED]> wrote: > Tim Chevalier wrote: > > > > Working on the documentation and external tools (with help from Andrew > > Tolmach) is my priority right now, as I need it for my own work. Thus > > *generating* External Core (and parsing it back in with an external > > tool) should be possible for mere mortals again soon. > > > That's great! >
Save your accolades for the day when it works :-) > > > (Using GHC to > > read it back in is probably never going to happen. I'd be happy to > > elaborate on why.) > > > Ok, I'll bite. Why? > There are two and a half reasons: 1) A bit of background first: We were going to use GHC interface files as a cheap and nasty way of representing External Core in a manner that's already easily parseable by GHC -- that is, it allows the input path (reading Core back into GHC) to be implemented easily. (IIRC, this was mostly Aaron Tomb's idea, with input from Simon PJ.) If you can trick GHC into thinking that everything needs an unfolding, then what you get is an interface file containing Core code for all the functions defined in a given module -- so, if you squint your eyes, an "External Core" file. The advantage of using interface files is that it avoids duplicating code within GHC; also, it's less prone to bit-rot, as the iface reading/writing code always has to work. But the disadvantages, and why we gave up on that idea, are (a) it throws the idea of External Core as a separate language with an independent semantics into serious peril, because external tool writers either have to import in interface-file parsing code from GHC or reinvent the wheel (or, we update the existing standalone External Core parser to handle interface files, which has the same reinventing-the-wheel problem), and (b) -- relatedly, but perhaps more importantly, the interface file format changes all the time, which defeats the purpose of having a stable external representation for Core. 2) Perhaps even more seriously, GHC keeps a great deal of analysis information attached to variables, and it doesn't really make sense to export much of it into External Core files -- external tools presumably mostly can't or don't want to make usage of strictness information, usage information, inlining information, etc. But then what happens when you want to read Core back in? Either GHC has to re-do all the analyses from scratch, or external tools have to supply it somehow -- in the latter case, external tools that want to read in Core, munge it, and feed it back into GHC have the obligation to preserve that analysis information in the course of the code transformations they do, and external tools that synthesize Core from scratch have an even harder task. Either way, the situation seems highly bogus. In short, Exp is simple, but Var is complicated. 2 1/2) I don't have particular motivation to invest time in thinking about how to overcome challenges (1) and (2), as I only need a working output path for my research project. I also don't see a lot of other people lining up to work on it. In essence, the dream of a modular GHC may be just that. Aren't you glad you asked? :-) Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "They killed, they maimed, and they called information for numbers they could easily look up in the book." -- Woody Allen _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
