Making GHCi awesomer?

[Benno Fünfstück]

2014-10-23 22:49 GMT+02:00 Luite Stegeman <stegeman at gmail.com>:

> If stability/segfaults are a major factor in choosing to communicate with
> the GHCi program, rather than using GHC as a library, then this really
> should be addressed directly. Has anyone done investigation of the
> situations that make ghc-mod/ghc-server, but not GHCi, crash?
>

The crashes tend to be related to linker problems (like duplicate symbols,
often also in combination with TH) IME.

I think the problem that projects like ghc-mod, hdevtools etc encounter is
that the GHC API is quite lowlevel. For example, just look at the code for
`:load`:
https://github.com/ghc/ghc/blob/5bb73d79a83bca57dc431421ca1e022f34b8dec9/ghc/InteractiveUI.hs#L1343
.

- First, I have no idea what abandonAll is doing here (and hdevtools isn't
using it). I guess it is related to GHCi debugger, so that might not be a
problem.
- We then unload the active program and call doLoad. doLoad just resets
some debugging related things (note that it calls discardActiveBreakPoints
again, even though loadModule' already did that) and then calls GHC.load.
After that, it calls `afterLoad`, which uses a foreign function calling
into the RTS (!) to reset CAFs. As this function is only foreign import'ed
in GHCi itself, I'm sure neither ghc-mod nor hdevtools call it.

Needing to call a RTS function just to safely load a new module, replacing
the old program, doesn't feel right to me. The problem here is that this
`loadModule` function is only inside GHCi, and not exported through the GHC
API.

This was just one example, I'm sure there are more. There is just no
highlevel GHC API function for most of GHCi's commands.
Another reason for the crashes might be that ghc-mod and hdevtools tend to
do many, many more reloads than GHCi, because they reload on every file
save (or even after 0.5s idle time). Crashes that only appear very
infrequent are thus much more likely to occur in ghc-mod.

--
Benno
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141024/67109bf3/attachment.html>