On 2/20/08, Roman Leshchinskiy <[EMAIL PROTECTED]> wrote:
> 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.
>
Okay, sure, I spoke a bit too hastily. Making use of the information
that GHC provides is one thing, though -- but how does an external
tool that does any program transformation maintain the correctness of
strictness info (etc.) without duplicating GHC's analysis machinery?
>
> > 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.
>
The dream, of course, is to provide not just a stand-alone language,
but a stand-alone language with a stand-alone semantics. So what are
the semantics of those pragmas, except in reference to GHC? You could
see them as optional, as you suggest, but let's be concrete: suppose
we use GHC to print out External Core, erase all internal annotations,
run an external program transformation on that Core code, and read the
resulting Core back into GHC. First, re-doing all that analysis is
expensive (in terms of compile times). Second, is this useful from the
perspective of the program transformation writer who wants to get
realistic data on how well the transformation is working -- given that
GHC does its simplifier loop, then the external transformation runs as
a single pass, then the simplifier runs again? Of course you could
iterate the whole process, but that gets really expensive, what with
the price of context switches.
That gets a little bit far afield from the problem of annotations, but
I hope you can see the point. Of course there are plenty of possible
external tools that aren't program transformation. I'm just talking
about the possible application I'm most familiar with.
>
> > 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 :-(
Better late than never :-)
Cheers,
Tim
--
Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt
"All we can ever do is lay a word in the hands of those who have put
one in ours." -- Richard Powers
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
