
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.
On Tue, Oct 8, 2019 at 10:37 AM Sam Halliday
Thanks Brandon,
Brandon Allbery
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
-- brandon s allbery kf8nh allbery.b@gmail.com