[GHC] #13128: Refactor AvailInfo to be more sensible
#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
#13128: Refactor AvailInfo to be more sensible -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 12662 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj):
`AvailInfo` has been the bane of my life for the last 12 months and I want to tame it.
I'm all for making things better! But while both (1) and (2) are valid complaints, but neither quite justifies "bane". Have you been hammered with efficiency problems from (2)? Has (1) really bitten you? Can you point to code that it painful as a result?
The next plan of attack is to distinguish between `IfaceAvailInfo` and `AvailInfo`.
That makes sense to me. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13128#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#13128: Refactor AvailInfo to be more sensible -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 12662 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I think (2) is significant and want to refactor to see. In another ticket pacak reported that the size of the build log was over 100mb because of warnings emitted from `ListSetOps`. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13128#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#13128: Refactor AvailInfo to be more sensible -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 12662 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): The new problem with this ticket now is that backpack signature files use the same interface files as regular modules. There are operations which merge signature files together and in doing so perform operations like monadically mapping over the names in `AvailTC`. I don't understand this well enough yet to refactor things properly. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13128#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#13128: Refactor AvailInfo to be more sensible -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 12662 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj):
In another ticket pacak reported that the size of the build log was over 100mb because of warnings emitted from ListSetOps
But are the warnings from usage in `AvailInfo`? Easy to find out by using `HasCallStack` info. Reason for asking: if the problem is somewhere else, it might be a better use of time to fix the somewhere else.
The new problem with this ticket now is that backpack signature files use the same interface files as regular modules.
But separating `IfaceAvailInfo` from `AvailInfo` may help this. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13128#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#13128: Refactor AvailInfo to be more sensible -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 12662 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * owner: mpickering => (none) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13128#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC