#2442: Heuristics to improve error messages for badly referenced things
----------------------------+-----------------------------------------------
 Reporter:  batterseapower  |          Owner:         
     Type:  proposal        |         Status:  new    
 Priority:  normal          |      Milestone:         
Component:  Compiler        |        Version:  6.9    
 Severity:  normal          |     Resolution:         
 Keywords:                  |     Difficulty:  Unknown
 Testcase:                  |   Architecture:  Unknown
       Os:  Unknown         |  
----------------------------+-----------------------------------------------
Comment (by batterseapower):

 Great!

 For posterity, the accompanying thread on Haskell-Cafe is at
 http://www.haskell.org/pipermail/haskell-cafe/2008-July/045175.html

 That thread also discusses what would be a cool improvement: searching all
 installed packages for the unbound name. However, that would require an
 actual index and as such is a bit of a heavier-weight solution.

 As a practical matter, I've been developing GHC using a stage1 compiler
 with this patch compiled into it and there is a noticable delay when
 displaying unbound name error messages if there are many things in scope.
 This is because I have made no attempt to optimize the code yet, and this
 needs to be resolved.

 Notes for me, when I get time to look at it:

  * Cache global reader environment elements between unbound name error
 messages (I'm guessing eltsUniqFM is fairly expensive)

  * Revert to the Levenshtein distance
 (http://en.wikipedia.org/wiki/Levenshtein_distance) rather than one that
 attempts to account for transpositions too, as the associated algorithm is
 considerably simpler. Unbox it to the hilt

  * Possibly adapt the distance metric so it operates in conjunction with a
 threshold distance it should bail out after

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2442#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Reply via email to