Proposal #2629: Data.List: Replace nub; add nubOrd, nubInt, nubWith

[Bart Massey]

Dan Doel <dan.doel <at> gmail.com> writes:
> Data.List is in the base package. Data.Set is in containers.
> 
> Data.Set also imports Data.List, so using sets in the latter creates a 
> circular dependency.

Oh.  Ow.  My bad for not doing a proper patch in the first place, which would
have exposed the problem before it got this far.  My apologies.  Thanks much for
the catch.

You said that the circular module dependency is "not as big a deal"?  I'm not
getting why...it seems pretty serious to me.  Is there some refactoring that
makes it go away without doing huge violence to the existing structure?  I mean,
we could split the Data.List module up into pieces to break the dependency, but
that doesn't seem like it's going to happen...

I'd completely forgotten about the recent package split of containers and base.
 No idea what to do there.  I suppose at worst we could have a Data.Nubs module,
but that just seems silly, as all it's going to export at this point is nubOrd
and (StopList-less) nubWith.  Besides, what package do we put it in?  Do we now
have container, base, and nubs?? :-) :-)

(In general, it seems like this sort of thing is going to become a problem as
the libraries grow.  I note, for example, that Data.Function is in base, which
makes putting any reasonable implementation of transitiveClosure in there pretty
hard for this same reason.)

Any suggestions from anyone about how to proceed?  Or are we just done at this
point?  So close...

    Bart Massey
    bart <at> cs.pdx.edu