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
foldl1 in changeset:8de16184.
Simon, do you still recall what you were thinking when you applied this commit ... 18½years ago? :-)