Tim Chevalier wrote:
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.
I disagree here. Off the top of my head, I can think of several useful
tools which could make use of this information.
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.
I don't quite see the problem, to be honest. If External Core is a
stand-alone language, then of course GHC has to redo the analyses. This
is what I would expect and unless I'm mistaken, GHC is quite capable of
doing this. It would be a nice bonus, of course, if External Core
allowed the information to be specified if it is available. A very
simple way of doing this would be something like pragmas, e.g.
{-# STRICTNESS foo = LL #-}
Tools could ignore, preserve or interpret such pragmas as they see fit.
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.
I'd like to lend a hand but probably just won't be able until the end of
April :-(
Roman
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
