[GHC] #11418: Suggest correct spelling when module is not found because of typo

[GHC]

#11418: Suggest correct spelling when module is not found because of typo
-------------------------------------+-------------------------------------
        Reporter:  syd               |                Owner:
            Type:  feature request   |               Status:  new
        Priority:  lowest            |            Milestone:
       Component:  Compiler          |              Version:
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  Incorrect         |  Unknown/Multiple
  warning at compile-time            |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by syd):

 Replying to [comment:27 simonpj]:
 > From Sven Panne: Just a few quick remarks:
 >
 > * Whatever you do, never walk the file system tree up or down in an
 uncontrolled way, this will kill basically all benefits and is a show-
 stopper. File systems like NFS, NTFS, stuff on USB sticks etc. are so
 **horribly** slow when used that way that the walks will probably dominate
 your compilation time. And even under Linux it's not uncommon to have a
 few dozen directory levels and hundreds of thousands of files below our
 cwd: Just check out a few repositories, have some leftovers from
 compilations, tons of documentations in small HTML files etc., and this
 sums up quickly. Git walks up the tree, but only looking for a specific
 directory and will e.g. not cross mount points under normal circumstances.
 This is probably the limit of what you can do.

 For the record: I never meant to walk the entire cwd, only source
 directories.

 While I get the general idea of 'never walk directory trees', in the end
 that is what you're doing anyway.
 In directories that only contain the source files, this approach would
 only reduce the amount of files opened.

 That said, I'm starting to think the cabal approach would be both easier
 and a smaller change.

 > * Caching between runs will be tricky: How will you invalidate the
 cache? People can (and will :-) do all kinds of evil things between runs,
 so how can you (in-)validate the cache quicker than re-scanning the file
 system again?
 Good point. Caching is probably not feasible here.

 > * As a general rule to keep in mind during the design: Successful
 compiler runs should not pay a price. It's OK if things are a little bit
 slower when an error occurs, but the main use case is successful
 compilation. This is a bit like exceptions in most programming language
 implementations: They are more or less for free when you don't use them
 (yes, they have a cost even then because they complicate/invalidate some
 compiler optimizations, but let's forget that for now), and are often
 costly when you actually raise them.
 Good feedback, thank you very much.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11418#comment:28>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler