> 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