Tim Chevalier wrote:
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?
If it can't or doesn't want to maintain it, it throws it away. The info
is optional: if it's there, it has to be correct but it doesn't have to
be there.
> 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?
Just like in Haskell, they don't have a semantics - they are essentially
comments. If a tool (like GHC) decides to interpret them somehow (this
should probably be enabled by a flag), that's a completely different
matter. This is of course not entirely optimal but should do for a start.
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).
I somewhat suspect that printing and parsing will dominate the
performance here to such an extent that redoing the analyses won't even
register.
> 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.
I'm not sure what the problem here is. Is it that you don't want to
rerun the simplifier after the external pass? That should be possible -
you don't (or shouldn't) need to simplify in order to do the analyses.
Roman
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
