FW: GHC API: Problems with implementing ":reload" for "ghc --make"

[Brian Smith]

On 11/24/06, Ian Lynagh <igloo at earth.li> wrote: > My goal is to write a
program GhcRemake that works like "ghc --make."

> > However, instead of terminating after compilation is done, I want the
> > program to stay open and wait for me to hit <ENTER>.


<snip>

> building the GHC API with it. Unfortunately, it seems like every build
> > after the first one in the session does the dependency analysis badly,
> > and things get recompiled unnecessarily.
>
> It looks like the problem is caused by recursive module imports. I've
> added a bug (#1027) with a smaller example of it.


Thanks. That was my suspicion as well. I currently have this utility on the
back burner while I am working on a different project. I had previously
filed issue 934 which is related to this issue. However, the workaround I
offered in 934 resulted in my program having poorer-than-expected
performance--with my patch applied, issuing two GHC.load's in the same
session was not significantly faster than it was without the patch applied.

Subsequently (and for other reasons than just performance), I started to
investigate a way to split up the pipeline into separate requests:
     x <- parseAndRename session
     y <- typecheck session
     z <- compileBytecodes session
     z' <- compileViaC session

However, I got discouraged from doing this because of the way errors are
handled in the renamer: when the renamer detects an error, it is likely to
stop without doing the rest of the renaming. However, I need the opposite
behavior: do as much renaming as possible, then return any naming errors,
then typecheck and return any type errors. This is the behavior an (fully
automatic) etags generator would want, which is more-or-less what I was and
will be building. But, it is not appropriate behavior for a the compiler
itself, so perhaps it is better to not use the GHC API for this program.

- Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20061124/f8637b66/attachment.htm