[GHC] #1799: ghci ':browse *<module>' does not list items in source order

[GHC]

#1799: ghci ':browse *<module>' does not list items in source order
------------------------+---------------------------------------------------
    Reporter:  guest    |        Owner:         
        Type:  bug      |       Status:  new    
    Priority:  normal   |    Milestone:         
   Component:  GHCi     |      Version:  6.6.1  
    Severity:  normal   |   Resolution:         
    Keywords:           |   Difficulty:  Unknown
          Os:  Unknown  |     Testcase:         
Architecture:  Unknown  |  
------------------------+---------------------------------------------------
Comment (by guest):

 i notice that :browse <module> does not seem to suffer from this issue, so
 the information in GHC.modInfoExports seems more stable than that in
 GHC.modInfoTopLevelScope. is that an accident or something we could rely
 on as a basis for ordering names?

 would it be possible to take the position of a name in its defining
 module's minf_exports NameSet, and add that to the name's srcLoc (in
 parens, to distinguish from proper srcSpans)? then we could list names in
 source order where we have the source, and in export order otherwise, both
 represented by comparing source location info.

 btw, i can think of several reasons why a name's srcLoc should be part of
 the defining module's interface. are the reason's against really stronger?

 for:

 - :browse could simply list names in source order, which is usually the
 right thing to do (are there any reasons for making the export order
 differ from the source order?)

 - ghc users could download library sources for libraries installed only as
 object code, and use ghci to navigate them (Hugs has supported this many
 many years with :find, and it is terrific both for beginners studying
 standard library code and for advanced users looking for issues with
 performance, etc.)

 - :ctags/:etags could be made to work with non-interpreted modules, so we
 could finally put hasktags to rest

 - ghc-based ide developers would have more information to work with

 - ghc developers could use any of the above to navigate ghc's sources

 against:

 - interface sizes would increase, though only by a line-number per
 exported item

 - interface comparison would need to ignore line-numbers, both for
 compatibility and for re-compilation (but doesn't already? the srcLocs are
 there as dummies)

 [claus] (where has the field for the commenter's name disappeared to?)

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