excessively long, redundant, compile-error-message contexts
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.
Trac metadata
| Trac field | Value |
|---|---|
| Version | 6.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |