JP Bernardy wrote:

...

map (append q1) listOfQueues

means that q1 is "prepended" to each queue.

* Rename subset & friends.

Similarly, they have an implicit infix meaning.

...

filter (subset s1) listOfSets

actually keeps sets that are supersets of s1.

Is there an agreed-upon (operator) name for this?

The problem with operator names is that they look ugly when qualified ("Seq.++"). Surely partial application "(subset s)" is different from a section "(`subset` s)" but is something that a Haskeller must learn anyway! Guess which argument "r" is in the instance "Functor ((->) r)". (This took me an age.)

* Make maps look more like collections of couples.

It's seems Haskell tradition to curry as much as possible (though this makes arguments and results non-symmetric, as in "quotRem" and "divMod")

* rename (<>) to (++)

Ok, but see above. Both a symbolic and a letter name are fine (like difference and \\).

* Make some types instances of Ord and Functor.

Yes! Furthermore: "MultiSet" should be named "Bag", Daans remark "that equality on elements should be defined as a structural equality instead of an equivalence relation." already applies to Set and Map! (Or may equal set look different when printed out?) Just my single cent, Christian

JP Bernardy wrote:

Then, I would propose a complete revised code, unless Daan wishes to do so.

It would be great if you can integrate the library in fptools -- just keep my name in the source code. I think though that it would be best if you first create a package with your proposal for review before adding it to fptools. Furthermore, we should add a proper BSD style license to all the sources. I have a specific license which I will send to you that should be attached, as I have agreed this license upon some (undisclosed) companies that are using the DData library. Here are detailed comments to your proposal:

* remove the Scc module

Seems to be redundant with SCC in Data.Graph

Not quite, it abstracts over the "Int" used to designate nodes and it returns the nodes in a very well specified order. I agree with you though that it is a rather strange module in the whole of DData and that it may be better to remove it.

* foldL, foldR, foldI -> foldl, foldr, foldi

to match Prelude.fold[lr]

The drawback of this is of course that you get even more name clashes with the prelude... requiring a "import Prelude" clause or "hiding (foldr, ...)" clause... Maybe it is better for the user to say "foldr = foldR" if they don't want to qualify their names?

remove find, favouring (!) and lookup.

What do you mean by this?

* rename "single" to "singleton"

Good plan, although I am in favor of adding "singleton" and marking "single" as deprecated in the documents. (so my old code can at least compile)

remove (Queue, Seq).append (favouring "<>")

I do not like this. I would rather vote for removing the operator. "append" is absolutely clear, while "<>" doesn't mean anything for the naive reader. That is why all my operators are also implemented by an explicit function.

...

map (append q1) listOfQueues

means that q1 is "prepended" to each queue.

Well, you can also write "map (q1 `append`) listOfQueues" :-)

* Rename subset & friends.

Good plan. Lets go for "isSubsetOf" or something.

* Make maps look more like collections of couples.

What !?! Why would you like to do that? It goes totally against the spirit of Haskell.

* rename (<>) to (++) * Make some types instances of Ord and Functor.

Maybe it is a good idea to make more data structures instances of Functor, Monad, and MonadPlus. Or maybe the proposed Monoid etc. Note that operations like "fmap" don't make sense for Set's as the type is more constraint, i.e.:

Set.map :: (a -> a) -> Set a -> Set a

This gives you the required behaviour, like "mappend" for concatenation. Things like (++) were specifically reserved for lists by the Haskell98 committee -- regardless whether you like it, I think we should stick with that philosophy. All the best, Daan.