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

[Dan Doel]

On Tuesday 30 September 2008 12:24:29 pm Bart Massey wrote:
> 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...

Well, in GHC, at least, there are ways to handle mutually recursive modules. 
I've never encountered the need myself, so I don't know the specifics, but it 
involves making an hs-boot file or something of the sort. Of course, that only 
works if they're in the same package, I suspect, so maybe it is a big problem. 
:)

I don't know how any other compilers handle such things.

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

Lists are a container, so I guess it'd be nice if Data.List could be moved to 
containers, but I think the prelude imports and uses stuff from it, and you're 
not going to move that.

nubOrd could be stuck in Data.Set, but that's kind of an odd place for it.

Other than that, I'm stumped.

-- Dan