#2439: Missed optimisation with dictionaries and loops -------------------------------------+------------------------------------- Reporter: rl | Owner: simonpj Type: bug | Status: new Priority: lowest | Milestone: 7.12.1 Component: Compiler | Version: 6.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ekmett): * cc: ekmett (added) Comment: @simonpj: Right now the reflection library (and a few other less savory libraries of mine) rely on the internals of a dictionary with one member and that member being the same thing so I can `unsafeCoerce` to build one. An example outside of the `reflection` library where we need to be able to build a dictionary out of whole cloth: {{{ data SNat (n :: Nat) where Snat :: KnownNat n => SNat n }}} Even if in a context we know `(KnownNat n, KnownNat m)`, we still can't derive `KnownNat (n + m)` with the current Nat solver. Yet having an operator {{{ (+) :: SNat n -> SNat m -> SNat (n + m) }}} for adding such `SNat`'s at the value level makes sense and things like that are important for many (if not most) applications of having a type level natural number type. I wind up having to backfill these things in by constructing dictionaries by hand. In theory, if I had to, I could start to rely on, say, it being the same as a one member data type instead if we decided to make that transition, so long as I have something available to me that has the right form that I could `unsafeCoerce` into a dictionary. Regarding performance impact: it'd introduce an extra pointer-dereference everywhere for dictionaries like `KnownNat` or `Reifies`, which currently just carry an `Integer` or a value in newtype form, but now would have an extra reference involved. It is not terribly significant, assuming light usage, but it is not free. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2439#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler