## #1606 closed bug (fixed)

# excessively long, redundant, compile-error-message contexts

Reported by: | Isaac Dupree | Owned by: | |
---|---|---|---|

Priority: | normal | Milestone: | |

Component: | Compiler | Version: | 6.6.1 |

Keywords: | Cc: | ||

Operating System: | Unknown/Multiple | Architecture: | Unknown/Multiple |

Type of failure: | None/Unknown | Test Case: | tcfail185 |

Blocked By: | Blocking: | ||

Related Tickets: | Differential Rev(s): | ||

Wiki Page: |

### Description

This is one single error message, with no good reason to go over, say, 24 lines...

(I thought there was a related bug report about long do-blocks in error messages, but I couldn't find it.)

IntegerInTermsOfInt.hs:2233:5: Couldn't match expected type `DInt -> DInt -> DInt -> [DInt]' against inferred type `[DInt]' In the expression: let n1 = isNegativeInteger i1 n2 = isNegativeInteger i2 nf = n1 `signOp` n2 rs1 = signRep n1 rs2 = signRep n2 rsf = signRep nf lowBits = pred intLargeBase highBits = complement lowBits repair = if nf then (\ d -> ...) else (\ d -> ...) fi (d1 : ds1) (d2 : ds2) = prepend df dsf where df = repair (((d1) `op` (d2))) dsf = f ds1 ds2 (signRep ((dNat (0)) > d1)) (signRep ((dNat (0)) > d2)) (signRep ((dNat (0)) > df)) fi (ds1@(_ : _)) [] = endOpWithNat ds1 fi [] (ds2@(_ : _)) = endOpWithNat ds2 fi [] [] = [] f (d1 : ds1) (d2 : ds2) s1 s2 sf = prepend df dsf where df = repair (((d1 + s1) `op` (d2 + s2)) - sf) dsf = f ds1 ds2 (sr s1 d1) (sr s2 d2) (sr sf df) f (ds1@(_ : _)) [] s1 s2 sf = f1 ds1 s1 s2 sf f [] (ds2@(_ : _)) s1 s2 sf = f1 ds2 s2 s1 sf f [] [] s1 s2 sf = f0 s1 s2 sf f1 i s1 s2 sf | s1 == sf = if isZero s2 then endOpWithNat i else endOpWithNeg i f1 [] s1 s2 sf = f0 s1 s2 sf f1 (d1 : ds1) s1 s2 sf = prepend df dsf where df = repair (((d1 + s1) `op` (s2)) - sf) dsf = f1 ds1 (sr s1 d1) (s2) (sr sf df) f0 s1 s2 sf = fromDInt df where df = repair (((s1) `op` (s2)) - sf) in fi i1 i2 (dNat (0)) (dNat (0)) (dNat (0)) In a lambda abstraction: \ i1 i2 -> let n1 = isNegativeInteger i1 n2 = isNegativeInteger i2 nf = n1 `signOp` n2 rs1 = signRep n1 rs2 = signRep n2 rsf = signRep nf lowBits = pred intLargeBase highBits = complement lowBits repair = if ... then ... else ... fi (d1 : ds1) (d2 : ds2) = prepend df dsf where df = ... dsf = ... fi (ds1@(_ : _)) [] = endOpWithNat ds1 fi [] (ds2@(_ : _)) = endOpWithNat ds2 fi [] [] = [] f (d1 : ds1) (d2 : ds2) s1 s2 sf = prepend df dsf where df = ... dsf = ... f (ds1@(_ : _)) [] s1 s2 sf = f1 ds1 s1 s2 sf f [] (ds2@(_ : _)) s1 s2 sf = f1 ds2 s2 s1 sf f [] [] s1 s2 sf = f0 s1 s2 sf f1 i s1 s2 sf | s1 == sf = if ... then ... else ... f1 [] s1 s2 sf = f0 s1 s2 sf f1 (d1 : ds1) s1 s2 sf = prepend df dsf where df = ... dsf = ... f0 s1 s2 sf = fromDInt df where df = ... in fi i1 i2 (dNat (0)) (dNat (0)) (dNat (0)) In the expression: \ i1 i2 -> let n1 = ... n2 = ... nf = ... rs1 = ... rs2 = ... rsf = ... lowBits = ... highBits = ... repair = ... fi (d1 : ds1) (d2 : ds2) = ... where df = ... dsf = ... fi (ds1@(_ : _)) [] = ... fi [] (ds2@(_ : _)) = ... fi [] [] = ... f (d1 : ds1) (d2 : ds2) s1 s2 sf = ... where df = ... dsf = ... f (ds1@(_ : _)) [] s1 s2 sf = ... f [] (ds2@(_ : _)) s1 s2 sf = ... f [] [] s1 s2 sf = ... f1 i s1 s2 sf | s1 == sf = ... f1 [] s1 s2 sf = ... f1 (d1 : ds1) s1 s2 sf = ... where df = ... dsf = ... f0 s1 s2 sf = ... where df = ... in fi i1 i2 (dNat (0)) (dNat (0)) (dNat (0))

Possibly the pretty-printer needs to know how to replace a long stretch of layout-expressions that aren't relevant to, or even very close to, the error, with "`...`

". Maybe something like (assuming I haven't misinterpreted where the error is coming from) :

In the expression: let n1 = isNegativeInteger i1 ... f0 s1 s2 sf = fromDInt df where df = repair (((s1) `op` (s2)) - sf) in fi i1 i2 (dNat (0)) (dNat (0)) (dNat (0))

Maybe if the contexts are greater than a certain length, GHC shouldn't print three of them, just two or one, also?

Also the "In a lambda abstraction" and the following "In the expression" appear to be followed by the same thing, except with more parts replaced with "`...`

" in the "expression". This is part of a function definition `tcBinOpInteger op signOp endOpWithNat endOpWithNeg = \i1 i2 -> let`

so, in this case, there _is no_ larger expression than the lambda abstraction...

By the way, the error's reported location was the "fi" right after the let's "in", and my coding mistake was that I shouldn't have been passing the three "zero" arguments. That was not helped at all in this case by thinking about those contexts... I can look at my own code! It would help if the part referred to by the error message's location was highlighted somehow (though that seems hard to do with plain text?)

Tested in 6.6.1 and 6.7.

### Change History (4)

### comment:1 Changed 10 years ago by

Resolution: | → fixed |
---|---|

Status: | new → closed |

Test Case: | → tcfail185 |

### comment:2 Changed 10 years ago by

Much better! For comparison, here is the new output from the same source-file.

IntegerInTermsOfInt.hs:2233:5: Couldn't match expected type `DInt -> DInt -> DInt -> [DInt]' against inferred type `[DInt]' In the expression: let n1 = isNegativeInteger i1 n2 = isNegativeInteger i2 nf = n1 `signOp` n2 .... in fi i1 i2 (dNat (0)) (dNat (0)) (dNat (0)) In the expression: \ i1 i2 -> let n1 = ... .... in fi i1 i2 (dNat (0)) (dNat (0)) (dNat (0)) In the definition of `tcBinOpInteger': tcBinOpInteger op signOp endOpWithNat endOpWithNeg = \ i1 i2 -> let ... in fi i1 i2 (dNat (0)) (dNat (0)) (dNat (0))

(And, well, if the fix is imperfect such that any particularly important information is left out in some cases due to the change, I'm sure we'll hear a bug report about that then)

### comment:3 Changed 8 years ago by

Architecture: | Unknown → Unknown/Multiple |
---|

### comment:4 Changed 8 years ago by

Operating System: | Unknown → Unknown/Multiple |
---|

**Note:**See TracTickets for help on using tickets.

Good points. I've improved

Thanks for reporting.

Simon