It's doing what you — but not ghc — consider "extra work", though. ghc expects to be compiling code, and doesn't have a separate code path for "load symbols from an external module by parsing its source code" instead of "load symbols from an external module by loading its .hsc file and object code", aside from HscInterpreted.
Thanks Brandon,
Brandon Allbery <allbery.b@gmail.com> writes:
> Cabal will build all that stuff the first time and then reuse it the next,
> so it's not quite the same thing. Since you told ghc no object code,
Sorry, I meant that I used targetAllowObjCode=True for everything,
except the file under inspection. Do you mean that if I used
targetAllowObjCode=False for just one module it will invalidate the
object code for everything it depends on? That is unexpected.
> In short, you may want to rethink this; ghc is a compiler, not an IDE, and
> doesn't quite work the way you had hoped.
How would you suggest rethinking it? Bare in mind that the api is
working exactly the way I want from a functional point of view (just
slow) with HscNothing... and seems to work exactly the way I want with
HscInterpreted (but with all the ghci caveats like unboxed tuples etc).
--
Best regards,
Sam
--