#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