[GHC] #9495: Do What I Mean RULES for foldr2 look shady

GHC ghc-devs at haskell.org
Sun Aug 24 06:53:56 UTC 2014


#9495: Do What I Mean RULES for foldr2 look shady
-------------------------------------+-------------------------------------
              Reporter:  dfeuer      |            Owner:
                  Type:  bug         |           Status:  new
              Priority:  highest     |        Milestone:  7.8.4
             Component:              |          Version:  7.8.3
  libraries/base                     |         Keywords:
            Resolution:              |     Architecture:  Unknown/Multiple
      Operating System:              |       Difficulty:  Unknown
  Unknown/Multiple                   |       Blocked By:
       Type of failure:  Runtime     |  Related Tickets:
  crash                              |
             Test Case:              |
              Blocking:              |
Differential Revisions:              |
-------------------------------------+-------------------------------------

Comment (by nomeata):

 The root of all this is the asymmetry of
 {{{
 Prelude> zip [] undefined
 []
 Prelude> zip undefined []
 *** Exception: Prelude.undefined
 }}}

 So what does the report say? It defined `zip` via `zipWith`:
 {{{
 zipWith          :: (a->b->c) -> [a]->[b]->[c]
 zipWith z (a:as) (b:bs)
                  =  z a b : zipWith z as bs
 zipWith _ _ _    =  []
 }}}
 At first I thought that this definition will imply `zipWith (+) [] ⊥ = ⊥`,
 but that doesn’t seem to be the case – pattern are tried from left to
 right.

 So while I dislike the slight asymmetry here, I don’t think it is
 justified to not follow the standard here.

 OTOH, I also don’t think that the semantic change, although a wart, is bad
 enough to justify not being able to fuse on one or the other side. I also
 think it is reasonable to try to fuse on boths sides (even if the result
 is not confluent if we could fuse on both sides).

 So I currently don’t see how to improve the code. Which leaves us
 improving the documentation. Would you provide a patch against that?

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


More information about the ghc-tickets mailing list