#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 dfeuer): Replying to [comment:3 nomeata]:
So while I dislike the slight asymmetry here, I don’t think it is justified to not follow the standard here.
We ''already'' aren't following the standard here! These are the three options I see (tl;dr: I think options 1 and 3 deserve serious consideration, and option 4 less; option 2 is more a Haskell Prime kind of question): 1. Eliminate `foldr1/right`, which will bring us into compliance with the standard, and change the documentation to indicate that we only fuse on the left list. The confluence problem is eliminated. The only downside is that if someone is relying on this rule, then their code will slow down. They will be able to fix this easily, but only if they pay attention to GHC release notes, are still maintaining their code, etc. 2. Change the baseline (not rewritten) definition of `foldr2` to check for nil on the second list first, and then eliminate `foldr1/left`. Document a violation of the standard. This also eliminates the confluence problem. I think it's arguably friendlier to fuse on the ''last'' argument than the first. That said, I don't think this is really a sensible option at this point because it has the downsides of most of the other options combined. 3. Change the baseline (not rewritten) definition of `foldr2` to force the second list to WHNF if the first is nil, rendering `foldr2` symmetrical. Document a violation of the standard. This approach ensures (I ''believe'') that the (still non-confluent) rules cannot produce bottoms that weren't there before. Personally, I would consider this the most conservative acceptable approach. 4. Leave things as they are in the code, but explain the situation in the documentation. I don't like this option, for the simple reason that code that runs correctly with `-O0` and doesn't do anything weird with funky `GHC.*.*` or `unsafe*` functions really should also run correctly with `-O`, but currently that is not the case. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9495#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler