[GHC] #2439: Missed optimisation with dictionaries and loops

[GHC]

#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