we can often produce much better code by directly solving for an available `Num Int` dictionary we might have at hand. This removes
#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 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