[GHC] #15632: Undependable Dependencies

[GHC]

#15632: Undependable Dependencies
-------------------------------------+-------------------------------------
        Reporter:  AntC              |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:  8.6.1
       Component:  Compiler          |              Version:  8.6.1-beta1
      Resolution:                    |             Keywords:
                                     |  FunctionalDependencies,
                                     |  OverlappingInstances
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:  10675, 9210,      |  Differential Rev(s):
  8634, 15135                        |
       Wiki Page:                    |
-------------------------------------+-------------------------------------
Changes (by AntC):

 * related:  10675, 9210, 8634 => 10675, 9210, 8634, 15135


Comment:

 Adding related ticket, particularly ticket:15135#comment:3 and SPJ's reply
 at comment 6 "This is terribly unsatisfactory".

 Changing the optimisation level or the per-instance pragmas can change
 which instance is selected, and thereby the meaning of the program -- even
 within a single module. (The O.P. for that ticket is the familiar 'orphan
 instances'/separate modules -- which is at least a devil we know.)

 The linked manual for `-fsolve-constant-dicts` says
 >  we can often produce much better code by directly solving for an
 available `Num Int` dictionary we might have at hand. This removes
 potentially many layers of indirection and crucially allows other
 optimisations to fire ...

 This seems to be muddling up concerns:
 - selecting which instance satisfies a Wanted constraint
   (in case of Overlapping instances, this means 'best'/most closely
 satisfies);
 - vs: having resolved which instance, ''and'' determined it's the same
 instance as for a dictionary available at hand,
   ''then'' sharing the at-hand dictionary/removing layers of indirection,
 etc.

 I can see that under separate compilation, we can't be sure whether the
 'best' instance in scope in the current module might get gazumped by an
 instance in another module. Then we can only go by the `OVERLAPPABLE`
 pragma. But we should always search all instances in scope in the current
 module, irrespective of pragmas or optimisation(?) OK that search is
 adding a performance hit for the compiler and it only makes a difference
 in case of overlap; but it shouldn't impact object code, presuming it does
 resolve to an at-hand dictionary.

 I didn't realise the pragmas had that dramatic of an effect on selecting
 instances. Then this applies from comment 1
 > I think it's arguable that an instance should only be overlappable if it
 says {-# OVERLAPPABLE #-}. But that's not our current spec.

 Making that the rule (in some form) could detect/warn of problematic
 'orphan instances'. Interpreting the rule for instances that are in no
 substitution order (the O.P. on this ticket #15632) still needs some head-
 scratching.

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