Please apply the comparison function given to nubBy to elements of the list in the order in which they occur in the list.
Edward Kmett
ekmett at gmail.com
Tue Sep 20 20:21:43 CEST 2011
On Wed, Sep 7, 2011 at 8:07 PM, Cale Gibbard <cgibbard at gmail.com> wrote:
> I just tried this in ghci-7.0.3:
>
> ghci> nubBy (>=) [1,2,3,4]
> [1]
>
> Think about what this is doing: it is excluding 2 from the list
> because 2 >= 1, rather than including it because 1 >= 2 fails.
>
> I think an important convention when it comes to higher order
> functions on lists is that to the extent which is possible, the
> function parameters take elements from the list (or things computed
> from those) in the order in which they occur in the original list.
>
> If we reimplement it in the obvious way:
> ghci> let nubBy f [] = []; nubBy f (x:xs) = x : filter (not . f x) (nubBy f
> xs)
> ghci> nubBy (>=) [1,2,3,4]
> [1,2,3,4]
>
> I'm aware that the Report (strangely!) explicitly leaves the behaviour
> of nubBy unspecified for functions which are not equivalence
> relations, but the behaviour given by the Report implementation (the
> opposite of the current behaviour in GHC) is useful and desirable
> nonetheless.
>
> I'm sure I've written about this before. I'm not entirely sure what
> happened to the previous thread of discussion about this, but it just
> came up again for me, and I decided that I was sufficiently irritated
> by it to post again.
>
I would suggest you rephrase this as a formal proposal, then I can happily
vote +1.
I'd also suggest rephrasing rhe mapAccumR as a formal proposal. I'm not sure
yet of whether or not I'd be behind that one, but make both proposals
separately, so they can pass individually.
A short email with the proposed change, and the "Discussion period: 2 weeks"
will either make this happen or not. This informal discussion, as it isn't
backing an actual proposal is just going to burn everyone out on the topic
and leave us where we started.
-Edward
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20110920/c144ac72/attachment-0001.htm>
More information about the Libraries
mailing list