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).
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).
T2528
Before this change, the output of base/tests/T2528.hs was (4x wrong):
[A,B] [1,2] False False
Lint OK |
No Unit Test Coverage |
Buildable 947 | |
Build 950: GHC Patch Validation (amd64/Linux) |
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.
Just to clarify: I don't care which way it goes, as long as everything matches afterwards.
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.