[GHC] #10859: Generated Eq instance associates && wrongly

[GHC]

#10859: Generated Eq instance associates && wrongly
-------------------------------------+-------------------------------------
              Reporter:  nomeata     |             Owner:  simonpj
                  Type:  bug         |            Status:  new
              Priority:  low         |         Milestone:
             Component:  Compiler    |           Version:  7.10.2
              Keywords:              |  Operating System:  Unknown/Multiple
          Architecture:              |   Type of failure:  None/Unknown
  Unknown/Multiple                   |
             Test Case:              |        Blocked By:
              Blocking:              |   Related Tickets:  #10858
Differential Revisions:              |
-------------------------------------+-------------------------------------
 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:8de16184643ea3c2f9f30b5eaed18db6ef247760.

 Simon, do you still recall what you were thinking when you applied this
 commit ... 18½years ago? :-)

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10859>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler