Preserve argument order to (==) and eq in nub and nubBy
ClosedPublic

Authored by thomie on Sep 22 2014, 4:00 PM.

Details

Summary

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).

Test Plan

T2528
Before this change, the output of base/tests/T2528.hs was (4x wrong):

[A,B]
[1,2]
False
False

Diff Detail

Repository
rGHC Glasgow Haskell Compiler
Branch
nubBy-D238
Lint
Lint OK
Unit
No Unit Test Coverage
Build Status
Buildable 1465
Build 1471: GHC Patch Validation (amd64/Linux)
thomie updated this revision to Diff 621.Sep 22 2014, 4:00 PM
thomie retitled this revision from to Preserve argument order to (==) and eq in nub and nubBy.
thomie updated this object.
thomie edited the test plan for this revision. (Show Details)
thomie added reviewers: austin, hvr, ekmett, dfeuer.
thomie updated the Trac tickets for this revision.
thomie updated this revision to Diff 623.Sep 22 2014, 5:08 PM
thomie edited edge metadata.

Fix ordering of test statements.

thomie edited the test plan for this revision. (Show Details)Sep 22 2014, 5:09 PM
dfeuer requested changes to this revision.Sep 22 2014, 9:38 PM
dfeuer edited edge metadata.

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.

This revision now requires changes to proceed.Sep 22 2014, 9:38 PM

Just to clarify: I don't care which way it goes, as long as everything matches afterwards.

dfeuer accepted this revision.Sep 29 2014, 6:14 PM
dfeuer edited edge metadata.
ekmett edited edge metadata.Sep 29 2014, 7:24 PM

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.

hvr requested changes to this revision.Sep 30 2014, 1:07 AM
hvr edited edge metadata.

Please don't forget an entry in libraries/base/changelog.md

ezyang removed a subscriber: ezyang.Oct 27 2014, 2:05 PM
thomie updated this revision to Diff 1087.Oct 29 2014, 5:46 AM
thomie edited edge metadata.

Add changelog entry

ekmett accepted this revision.Nov 7 2014, 9:56 AM
ekmett edited edge metadata.

LGTM

austin accepted this revision.Nov 7 2014, 9:58 AM
austin edited edge metadata.

LGTM.

hvr accepted this revision.Nov 7 2014, 10:33 AM
hvr edited edge metadata.

let's do this...

This revision is now accepted and ready to land.Nov 7 2014, 10:33 AM
This revision was automatically updated to reflect the committed changes.