This makes nub and nubBy behave the same as in the 98 report.
This reverts 0ad9def53842e86fb292eccb810190711c42d7c5, and fixes Trac #3280, Trac #7913 and Trac #2528 (properly).
Details
Details
T2528
Before this change, the output of base/tests/T2528.hs was (4x wrong):
[A,B] [1,2] False False
Diff Detail
Diff Detail
- Repository
- rGHC Glasgow Haskell Compiler
- Branch
- nubBy
- Lint
Lint OK - Unit
No Unit Test Coverage - Build Status
Buildable 947 Build 950: GHC Patch Validation (amd64/Linux)
Comment Actions
I like what you're trying to do, but I have one concern: this behavior appears to be around six years old now. Might anyone actually rely on it? Obviously, we need to make sure the documentation matches the true behavior, and that (by the time the next Report comes out) the GHC behavior matches the Report behavior, but I just want to make sure everyone agrees that GHC should change to match the Report and not the other way around.
Comment Actions
Just to clarify: I don't care which way it goes, as long as everything matches afterwards.
Comment Actions
Comment from Cale Gibbard:
I would like to be able to rely on the original behaviour of the algorithm in the report. I think in general whenever we have a higher order function which applies some function to elements drawn from a list, and there's a choice about which order the arguments to that function go in, we should preserve the order in which they occurred in the list.