summaryrefslogtreecommitdiff
path: root/utils
diff options
context:
space:
mode:
authorsimonpj@microsoft.com <unknown>2007-02-27 23:13:13 +0000
committersimonpj@microsoft.com <unknown>2007-02-27 23:13:13 +0000
commit5b51ce96dae021692d45b9aed5ac7bfe39b237bc (patch)
tree0ca5a3b9ec4e2c0d7e644b1d672e7b36005e1b5a /utils
parentdc04a79e54bcbeff4008df333fe416104a280121 (diff)
downloadhaskell-5b51ce96dae021692d45b9aed5ac7bfe39b237bc.tar.gz
Make let-matching work in Rules again
A RULE is supposed to match even if there is an intervening let: RULE f (x:xs) = .... target f (let x = thing in x:xs) It's surprisingly tricky to get this right; in effect we are doing let-floating on the fly. I managed to get it wrong before, or at least be over-conservative. And in "fixing" that I got it wrong again in a different way, which made it far too conservative. In particular, it failed to match f (let x = y+y in let z=x+y in z:xs) because the binder x was cloned and looked "locally-bound". See the ever growing comments with the Let rule for details. That patch reverts to the previous story, which is still a bit too conservative, but not so egregiously so. Fixes Romans's problem.
Diffstat (limited to 'utils')
0 files changed, 0 insertions, 0 deletions