slow load and typecheck

[Brandon Allbery]

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 <sam.halliday at gmail.com> wrote:

> Thanks Brandon,
>
> Brandon Allbery <allbery.b at 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
>


-- 
brandon s allbery kf8nh
allbery.b at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20191008/4ab5767c/attachment.html>