[GHC] #8832: Constant-folding regression wrt `clearBit (bit 0) 0 `

[GHC]

#8832: Constant-folding regression wrt `clearBit (bit 0) 0 `
-------------------------------------+-------------------------------------
        Reporter:  hvr               |                   Owner:  ekmett
            Type:  bug               |                  Status:  new
        Priority:  high              |               Milestone:  7.12.1
       Component:  Core Libraries    |                 Version:  7.8.1-rc2
      Resolution:                    |                Keywords:
Operating System:  Unknown/Multiple  |            Architecture:
                                     |  Unknown/Multiple
 Type of failure:  Runtime           |               Test Case:
  performance bug                    |  simplCore/should_compile/T8832
      Blocked By:                    |                Blocking:
 Related Tickets:                    |  Differential Revisions:
-------------------------------------+-------------------------------------

Comment (by bgamari):

 For the record, hvr has indicated that he will eventually be implementing
 a more efficient `bitInteger`. However, this still means that `Integer`
 won't get proper constant folding (as it won't be implemented in terms of
 `shiftL`).

 I'm not really sure it's fair to call this a library problem: the compiler
 currently makes the library author choose between having a constant-folded
 `bit` implementation (by implementing in terms of other operations which
 are constant folded) or an implementation which is implemented efficiently
 for the type in question. There are a few ways we could handle this:

  1. add a `PrelRule` to specifically handle `Bits.bits`
  2. somehow extend the rule rewriting system to allow these rules to be
 expressed in the source language

 Option 1 is unfortunate in that `Bits.bits` is likely far from the last
 operation which will need this treatment. Moreover, it leaves users who
 want to implement other types implementing `Bits` and similar classes
 covered by `PrelRules` high and dry.

 Arguably this is a limitation of the rule rewriting system, hence option
 2. At first glance it would seem like allowing a rule to match conditioned
 on the nature of its arguments (either literal or non-literal) and
 allowing compile-time evaluation of the RHS may be sufficient to address
 this. This, however, would be non-trivial to implement (namely compile-
 time evaluation would require the interpreter) and may present termination
 issues. For these reasons (and perhaps others I haven't yet thought of) I
 doubt this is a viable path.

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