On 11/24/06, Ian Lynagh
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