| > Dan, can you suggest any words we could add to the | > documentation that would have prevented you stumbling? | | I guess the thing that would have helped best would have been an error | message like "'x' not in scope, use -fforce-recomp to see all symbols" | when running interactively in ghci with a previously compiled top | level module. I agree that an informative error message is worth 100 manual pages. The trouble is that at this stage GHCi doesn't even *know* that 'x' ever existed, because it's not mentioned in the interface file, so it's hard to do even give the error message you suggest. (I forgot to mention that GHCi will let you run code in modules that are only available in compiled form, such as ones from other packages -- there is no source code to consult.) I can think of some other possibilities: (a) It would be possible to record in the .hi file the fact that there originally *was* a top-level 'x', and so produce the message you suggest. But it'd be one more thing to implement, document, and maintain. (b) We could decide *never* to use compiled modules (M.o) for home-package modules, but only for other-package modules. Then at least all the home-package modules would have their names in scope. So the home package would be always interpreted. (The home package is the modules of your current project, not installed as a "package".) This'd be pretty easy. (c) The last thing I can think of is that we could *read the source code* for home-package modules M (to find the top-level definitions), but still use the M.o files if they exist (to get faster execution). Then we could produce the message you suggest. If any of this seems important enough to you to be worth doing, would you like to create a feature-request ticket for it, and summarise the discussion and alternatives? Simon