[GHC] #13128: Refactor AvailInfo to be more sensible

[GHC]

#13128: Refactor AvailInfo to be more sensible
-------------------------------------+-------------------------------------
           Reporter:  mpickering     |             Owner:  mpickering
               Type:  task           |            Status:  new
           Priority:  low            |         Milestone:
          Component:  Compiler       |           Version:  8.0.1
           Keywords:                 |  Operating System:  Unknown/Multiple
       Architecture:                 |   Type of failure:  None/Unknown
  Unknown/Multiple                   |
          Test Case:                 |        Blocked By:
           Blocking:                 |   Related Tickets:
Differential Rev(s):                 |         Wiki Page:
-------------------------------------+-------------------------------------
 `AvailInfo` has been the bane of my life for the last 12 months and I want
 to tame it. There are two main problems with it.

 1. There is this horrible invariant where if the parent is also exported
 then it is the first element of the list of children.
 2. The set of children and field labels are represented as lists which
 means many expensive calls to functions from `ListSetOps`.

 1 Is easy enough to solve by adding a flag which says whether the parent
 is exported or not.

 My naive attempt to solve the second problem was to replace the list by a
 `NameSet`. At the interface file boundary, the `NameSet` is converted into
 a list using `nameSetElemsStable` to maintain determinism and only pay the
 cost of using this expensive function once. This ran into problems in
 `RnModIface` where there are several functions which map over the list of
 children. NameSets don't support mapping and so this is difficult to
 implement in a satisfactory way.


 The next plan of attack is to distinguish between `IfaceAvailInfo` and
 `AvailInfo`. The former will use the old representation (lists) in order
 to maintain determinism but the latter will use sets. Distinguishing the
 two modes is useful conceptually and practically.

 The data type is used in quite a few different ways in lots of places
 which makes writing a nice interface hard.

 This ticket is to record my trail in case I don't make it to the end.

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