Status of nubOrd (Proposal #2629)

[David Menendez]

On Mon, Oct 6, 2008 at 12:13 AM, Brandon S. Allbery KF8NH
<allbery at ece.cmu.edu> wrote:
> On 2008 Oct 6, at 0:07, David Menendez wrote:
>>
>> On Sat, Oct 4, 2008 at 3:26 AM, Bart Massey <bart at cs.pdx.edu> wrote:
>>>
>>> I need to know what the community wants me to do to close
>>> out my proposal to add nubOrd to the standard libraries.
>>> After ruling out a lot of marginal choices, I guess I see
>>> three leading alternatives, all of which have negatives.
>>> I'd love to have some feedback on these so I can start
>>> thinking about other things.
>>
>> I realize I'm coming into this discussion late, but has anyone
>> surveyed existing Haskell code to see how often nub is used? How many
>
> It's not so much that nub is used often. it's that it's often
> *reimplemented*.

By people who *need* a faster nub, or by people who figured they could
make nub faster by changing the type? How often does someone need the
exact behavior of nub, instead of something faster like "Set.toList .
Set.fromList"?

All this effort to optimize a seemingly obscure function feels like
overkill. We might be better off just adding a note to the
documentation of nub suggesting that people use Data.Set instead. (We
can't get rid of it, because it's in the H98 Report.)

In any case, my only objection is to complicating the standard
libraries. If someone wants to post a faster nub to Hackage, that's
fine.

>> If there are really a lot of cases where people need a collection that
>> (1) has no duplicates, and (2) preserves an arbitrary order of
>> elements, maybe we'd be better off designing a data structure
>> specifically for that.
>
>
> Feel free to contribute.  Make sure it supports the whole spectrum of list
> operations, including list comprehensions.

Demonstrate the need, and I'd be happy to contribute.

-- 
Dave Menendez <dave at zednenem.com>
<http://www.eyrie.org/~zednenem/>