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