Generated Eq instance associates && wrongly
Currently, we derive this code for (==)
:
(==)
(ImportDecl a1_acXi
a2_acXj
a3_acXk
a4_acXl
a5_acXm
a6_acXn
a7_acXo
a8_acXp)
(ImportDecl b1_acXq
b2_acXr
b3_acXs
b4_acXt
b5_acXu
b6_acXv
b7_acXw
b8_acXx)
= (((((((((a1_acXi == b1_acXq)) && ((a2_acXj == b2_acXr)))
&& ((a3_acXk == b3_acXs)))
&& ((a4_acXl == b4_acXt)))
&& ((a5_acXm == b5_acXu)))
&& ((a6_acXn == b6_acXv)))
&& ((a7_acXo == b7_acXw)))
&& ((a8_acXp == b8_acXx)))
To me this looks wrongly associated: Since &&
is strict in the left but lazy in the right argument, shouldn’t this be associated the other way around? The compiler might clean it up later, but why not produce it correctly right away?
The culprit is this line:
= foldl1 and_Expr (zipWith3Equal "nested_eq" nested_eq tys as bs)
and I was just about to change that ot foldr1
, but then I did some git-archeology and found that Simon changed that deliberately from foldr1
to foldl1
in changeset:8de16184.
Simon, do you still recall what you were thinking when you applied this commit ... 18½years ago? :-)
Trac metadata
Trac field | Value |
---|---|
Version | 7.10.2 |
Type | Bug |
TypeOfFailure | OtherFailure |
Priority | low |
Resolution | Unresolved |
Component | Compiler |
Test case | |
Differential revisions | |
BlockedBy | |
Related | |
Blocking | |
CC | |
Operating system | |
Architecture |